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INTRODUCTION 


I . 


In  recent  years,  the  Department  of  Defense  (DoD) 
shifted  from  a  threat-based  model  to  a  capabilit ies-based 
model  for  military  operations  (CJCS,  2000)  .  This  shift 
occurred  because  we  no  longer  know  with  any  certainty  where 
or  how  our  military  resources  will  be  required.  The 
evolution  of  a  capabilit ies-based  military,  as  outlined  in 
the  Joint  Vision  2020  (CJCS,  2000),  requires  that  our 
military  be  more  mobile,  flexible,  and  interoperable 
(joint)  then  ever  before.  Today,  Network  Centric 
Operations  (NCO)  has  become  an  important  means  to  provide 
information  to  decision  makers.  Our  military  can  now 
quickly  exchange  and  process  information  so  that  navy  goals 
such  as  munitions  on  target  and  expedient  routing  of  ships 
around  storms  can  occur. 

This  change  of  focus  is  as  relevant  to  the  Meteorology 
and  Oceanography  (METOC)  community  as  it  is  to  "Big  Navy". 
Today  we  provide  things  like  satellite  images  or  weather 
briefings  in  stand-alone  PowerPoint  slides,  but  this  must 
change.  These  new  times  mandate  that  we  become  more 
integrated  and  interoperable  with  the  decision  makers  and 
warfighters.  By  increasing  its  interoperability,  the  METOC 
community  will  "remain  strategically  engaged  and  become 
significantly  more  operationally  and  tactically  aligned  by 
providing  decision  makers  with  knowledge  that  is  specific 
to  the  warfighter  platform,  system,  weapon,  etc." 
(Oceanographer  of  the  Navy,  2002)  . 

This  new  business  model  will  force  the  METOC  community 
to  modify  the  way  it  provides  current  products  and 
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services,  requiring  new  methods  and  tools  to  create  new 
products  and  services.  Today,  our  computer  software 

programs  and  services  in  the  METOC  community  have  been 
largely  developed  by  local  commands.  This  resulted  in  very 
good  programs  like  the  Joint  METOC  Viewer  ( JMV) ,  Naval 
Oceanographic  Data  Dissemination  System  (NODDS),  Online 
Messaging  System  (OMS),  or  the  current  OTSR  tracking 
databases,  that  met  the  local  command  requirements,  but  are 
not  interoperable  with  the  warfighter  or  other  METOC 
commands.  Current  application  that  provide  data  to  the 
fleet  like  JMV,  GFMPL,  TAWS,  AREPS,  IMAT,  NOWS,  Access, 
Word,  Excel,  Notepad  provide  static  pictures  or  text 
products  that  require  a  man  in  the  loop  to  process  and 
present  the  product  to  the  customer. 

A.  STATEMENT  OF  THESIS  GOALS: 

The  goal  of  this  thesis  is  to  improve  interoperability 
of  METOC  product  and  services  by: 

1.  Enabling  the  forecaster  tool  of  choice,  the  Joint 
METOC  Viewer  (JMV) ,  to  produce  products  (ESRI  Shape 
formatted  Horizontal  Weather  Depictions  (HWD)  and  ship 
tracks)  that  can  be  displayed  on  a  tactical  display. 

2.  Improving  the  METOC  product  dissemination  tool, 
METCAST,  to  allow  easy  transfer  of  Regional  Center  created 
products  (HWD's  and  ship  tracks)  to  customers,  staffs,  and 
other  Regional  Centers. 

3.  Upgrading  existing  Optimum  Track  Ship  Routing 
(OTSR)  database  into  an  Electronic  Ship  Folder  that  would 
not  only  make  all  OTSR  Centers  more  interoperable,  but 
increase  the  efficiency  of  the  database  by  including  all 
elements  of  the  OTSR  system  (e.g.,  message  support. 
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database  tracking,  automated  report/metrics  generation  and 
automated  web  page  production) . 

Each  of  these  individual  projects  improves  the  ability  of 
the  METOC  community  to  better  serve  itself  and  the  fleet 
with  more  timely,  accurate  and  tailor-made  products.  This 
thesis  also  proposes  a  concept  of  operations  for  how  future 
METOC  (possibly  more  mesoscale)  products  can  and  should  be 
provided . 

B.  INTEROPERABILITY  WITH  THE  WARFIGHTER 

Today,  only  a  few  METOC  products,  such  as  high  winds 
and  high  seas  warnings,  tropical  forecasts  and  NAVO  REACT 
products  are  produced  in  a  format  that  can  be  displayed  on 
the  warfighter  display  systems  (e.g..  Global  Command  & 
Control  System  (GCCS) ,  ESRI  ARCVIEW/ARCINFO) .  In  an  effort 
to  increase  the  interoperability  of  METOC  products  with 
tactical  displays,  improvements  have  been  made  to  JMV  to 
allow  viewing  of  HWD's  and  ship  tracks  in  ARCVIEW  and 
Polexis  Viewpoint.  This  process  was  tested  during  FBE-J  as 
part  of  the  Geospatial  Enhanced  METOC  (GEM)  program  being 
coordinated  by  the  center  in  San  Diego.  Although  this 
project  only  tested  a  limited  subset  of  METOC  products,  it 
has  established  the  CONOPS  and  determined  problem  areas  for 
developing  additional  capabilities. 

C.  IMPROVED  COMMUNICATIONS  FOR  REGIONAL  CENTER  PRODUCTS 

Traditionally,  Navy  METOC  Regional  Centers  have 
produced  products  either  in  a  text-based  format  for 
transmission  over  the  Navy' s  messaging  system  or  graphical- 
based  formats  that  were  pushed  to  a  web  site.  These  data 
formats  were  adequate  for  support  within  a  particular 
centers  Area  of  Responsibility  (AOR) ;  however,  when  support 
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for  a  command  crossed  traditional  AOR  boundaries,  no  simple 
method  existed  to  produce  a  consolidated  product.  As  a 
result,  staffs  and  regional  centers  where  forced  to  brief 
multiple  slides  or  manually  recreate  products  from  other 
centers,  wasting  valuable  resources.  In  this  effort, 
improvements  were  made  to  the  METCAST  Channels  system  to 
allow  multiple  products  from  multiple  product  producers  to 
be  quickly  and  easily  uploaded  and  downloaded.  Now 
disparate  or  geographically  separated  products  can  be 
merged  to  create  single  consolidated  basin,  hemispheric  or 
global  products.  The  scope  of  this  thesis  is  to  conduct 
this  process  using  HWD's  and  ship  tracks.  HWD's  and  Ship 
tracks  traditionally  are  two  important  METOC  products  that 
require  coordination  between  centers  and  are  required  by 
centers,  and  by  Operational  and  Type  Commanders. 

D.  ELECTRONIC  SHIP  FOLDER 

The  OTSR  program,  which  will  be  discussed  more  in 
Chapter  II,  is  operated  by  various  centers  around  the  globe 
and  provides  cost  savings  and  storm  avoidance  services  for 
vessels  transiting  large  ocean  basins.  Running  an  OTSR 
program  requires  that  Regional  Centers  have  ways  to 
retrieve  and  view  current  weather  data,  monitor  operational 
message  traffic,  track  the  requested  OTSR  support,  and 
supply  the  latest  OTSR  data  to  appropriate  commanders. 
Although  the  end  product  of  the  OTSR  process  for  Regional 
Centers  is  identical,  current  support  methods  differ  from 
center  to  center  causing  inefficiencies  and  database 
mismatches.  As  a  ship  transits  from  one  AOR  to  another, 
data  entered  into  one  database  must  be  manually  replicated 
to  the  database  at  the  second  regional  center.  To  improve 
the  interoperability  in  this  program  a  comprehensive 
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Electronic  Ship  Folder  system  has  been  developed  that  will 
improve  the  maintenance  of  the  OTSR  program  and  improve 
interoperability  between  regional  centers.  The  scope  of 
this  project  will  include  a  database  for  support  tracking, 
message  dissemination  tools  to  automate  some  data  entry, 
and  upgrades  to  JMV  and  METCAST  that  allows  easier  product 
development  and  dissemination. 
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II.  PROGRAM  AND  SERVICE  OVERVIEW 


This  chapter  will  discuss  the  programs  used  in  this 
thesis,  JMV  and  METCAST  and  provide  a  brief  description  of 
the  basic  structure  of  a  NMOC  Center  OTSR  program.  The 
deficiencies  discussed  will  be  confined  to  only  issues 
related  to  JMV,  METCAST  and  the  distribution  of  HWD  and 
Ship  route  products 
A.  JMV 

1 .  Background 

JMV  is  a  program  developed  by  SPAWAR  and  Fleet 
Numerical  Meteorology  and  Oceanography  Center  in  Monterey, 
CA.  JMV  is  compatible  with  the  Microsoft  Windows  OS 
family.  Sun  Solaris  and  HPUX.  JMV  is  used  to  display 
gridded  model  data,  satellite  imagery,  surface  and  upper 
air  observations,  along  with  many  other  types  of 
meteorological  and  oceanographic  data  (FNMOC,  1999) .  The 
gridded  data  that  is  displayed  can  be  viewed  in  standard 
contour  maps  or  as  horizontal  and  vertical  cross-sections. 
To  formulate  a  forecast,  raw  data  can  be  overlaid  with 
METOC  symbology  to  produce  meteorological  products  (e.g., 
HWD's,  Analysis  Charts,  High  Winds  and  Seas)  as  well  as 
situational  awareness  and  analysis  tools  (e.g..  Ship  Tracks 
and  Storm  Tracks)  .  JMV  is  the  backbone  for  current  Naval 
meteorological  forecasting;  used  in  Ocean  Basin  and 
Operations  Area  (OPAREA)  forecasting.  Ship  routing  (OTSR) , 
Flight  forecasts  using  the  Optimum  Path  Aircraft  Routing 
Software  (OPARS),  airport  observations  and  forecast 
display . 
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2. 


Deficiencies : 


In  the  production  of  tactically  relevant  products  or 
the  automatic  generation  of  Center  "value  added"  products, 
JMV  needs  to  have  the  capability  to  output  shape  formatted 
products  and  be  able  to  add  manually  generated  products  to 
the  slide  show  feature. 

a.  Tactically  Relevant  Products 

The  ability  to  know  where  your  forces  are  in 
relation  to  your  enemy  is  extremely  valuable.  Force 
locations  combined  with  current  intelligence  (e.g.,  troop 
movements,  missile  launches,  signal  detection,  etc.)  and 
weather  is  vital  to  mission  planning  and  execution.  The 
Navy  GCCS  system  provides  the  common  operational  picture 
(COP)  used  to  display  real-time  and  near  real-time  battle 
space  information.  Recently  the  Naval  Special  Warfare 
(NAVSPECWAR)  Command  began  to  use  commercial  products 
(e.g.,  ARCINFO,  ARCVIEW,  ARCGIS)  from  ESRI  that  allows  geo- 
located  and  ortho-rectified  information  (satellite  images, 
chart  and  map  products,  tactical  Products)  to  be  overlaid 
on  the  same  display.  In  order  to  fuse  METOC  products 

into  the  tactical  picture,  the  METOC  community  must  produce 
products  in  compatible  formats.  In  July  2002,  DoD  awarded 
a  contract  to  ESRI  for  the  Combined  Joint  Mapping  Tool  Kit 
(CJMTK)  that  may  become  the  next  Generation  COP  by  year 
2012.  The  METOC  community  only  provides  High  Winds,  High 
Seas  and  Tropical  Warnings  to  the  current  GCCS  COP. 
Additionally,  some  Naval  Oceanographic  Office  products  are 
being  produced  in  shape  format  for  use  in  ESRI's  ARC 
Products.  Minor  upgrades  to  JMV  will  allow  us  to  produce 
meteorological  products  into  ESRI's  shape  format  and  thus 


allow  METOC  products  to  be  viewed  directly  by  NAVSPECWAR 
and  the  future  COP . 

b.  Auto  Generation  of  NMOC  Center  "Value  Added" 
Products 

JMV' s  Slide  Show  production  capability  allows 
users  to  create  presentations  used  for  analysis  or  for 
creating  weather  products  for  customers.  Presentations  are 
produced  by  combining  various  types  of  METOC  data  like 
satellite  images,  gridded  model  data,  observations,  and 
combined  on  a  common  background  map  display.  Data  is 
automatically  updated  whenever  the  latest  METCAST  download 
occurs.  Data  is  retrieved  using  METCAST,  the 

publish/subscript ion  service,  from  the  Tactical 

Environmental  Data  Server  (TEDS) ,  located  at  FNMOC  or  any 
of  the  Regional  Centers.  Although  these  products  are 
useful  for  the  meteorologist  to  use  for  comparing  the 
various  model  output  with  satellite  data  and  local  analysis 
products,  they  are  not  particularly  useful  to  the  novice 
who  just  wants  to  know  basic  weather,  like  visibility  or 
temperature.  These  novice  customers  are  actually  provided 
with  an  interpretation  of  the  model  and  satellite  data  that 
is  prepared  by  the  METOC  Regional  Center  called  "value 
added  products".  Unfortunately  these  "value  added 

products"  are  not  currently  part  of  TEDS  and  METCAST. 
Today  they  are  merely  saved  to  a  local  server  or  hard  drive 
thus  JMV  and  METCAST  do  not  know  they  are  available  and  can 
not  update  the  slide  show  presentation.  The  result  of  this 
deficiency  is  that  personnel  from  the  center  must  recreate 
the  product  from  scratch.  If  JMV  were  aware  of  the  "value 
added  products"  and  automatically  updated  web  pages  it 
could  save  many  hours  of  tedious  and  redundant  work. 
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B .  METCAST 

1 .  Background 

METCAST  is  a  standards  based,  request-reply  and 
subscription  system  used  for  distributing  weather  and 
oceanographic  data.  The  METCAST  System  is  made  up  of  the 
METCAST  Servers  located  at  FNMOC  or  at  any  of  the  Regional 
Centers  located  around  the  globe  and  the  METCAST  Client 
that  is  used  by  the  local  user.  Data  is  delivered  by 
METCAST  over  the  Internet,  NIPRNET  or  SIPRNET  using  Hyper¬ 
Text  Transfer  Protocol  (HTTP)  and  Multipurpose  Internet 
Mail  Extensions  (MIME) .  METCAST  users  interact  with  the 
program  by  using  the  METCAST  Client  Graphical  User 


Interface 

(GUI) 

t ,  which 

allows  a  user 

to  select 

a  region 

of 

interest , 

the 

products 

to  be  retrieved,  as 

well  as 

the 

frequency 

and 

type  of 

retrieval . 

Once  the 

region 

and 

product  types  have  been  created,  the  region  is  scheduled 
for  download  and  the  retriever  process  is  started  which 
establishes  the  communications  path  between  the  METCAST 
Client  (user  interface)  and  the  METCAST  Server. 

METCAST  currently  has  two  methods  of  retrieving  data 
via  the  METCAST  Client.  The  request-reply  is  used  for 
requesting  established  products  from  the  METCAST  Server, 
which  are  typically  model  output,  satellite  imagery,  and 
observational  data  that  FNMOC  produces  or  collects  and  then 
distributes.  The  other  method  of  data  retrieval  is  to  use 
the  METCAST  Channels  where  METCAST  clients  can  publish  and 
retrieve  many  different  data  types  ranging  from  center 
generated  forecasts,  documents,  PowerPoint  presentations  or 
simple  text  files.  The  advantage  of  this  method  is  that 
METCAST  Clients  can  publish  information  at  will  and  as  long 
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as  the  required  attribute  information  is  provided  the 
product  will  be  validated  and  posted  to  the  channel.  Once 
the  product  is  posted,  it  is  available  to  anyone  who  has  a 
METCAST  client  or  any  other  product  that  has  access  to  the 
METCAST  Server  (i.e.,  Polexis  Viewpoint) .  As  stated  in  the 
introduction,  one  of  the  goals  of  this  thesis  was  to 
improve  the  interoperability  within  the  community  and  the 
METCAST  Channels  provide  quick  access  to  products  between 
centers,  staffs  and  the  warfighter. 

2 .  Deficiencies 

The  original  version  of  the  METCAST  Channels  server 
required  that  each  channel  contain  only  one  type  of  data 
(e.g.,  text  products,  jpg  graphics,  gif  graphics, 
PowerPoint  presentations,  etc.)  and  that  only  one  version 
of  each  type  of  product  exist  at  one  time.  Additionally, 
the  METADATA  or  attributes  available  to  sort  the  data  was 
insufficient  to  provide  easy  access  to  the  intended  data. 
These  restrictions  meant  that  if  this  system  were  to  be 
used  to  provide  OTSR  Ship  Track  data  for  a  particular 
regional  center,  then  a  new  channel  would  need  to  be 
created  for  every  published  ship  track.  Since  each  of  the 
three  Centers  that  provide  OTSR  services  continuously  track 
anywhere  from  20  -  100  ships,  the  maintenance  on  this  type 
of  system  would  quickly  become  unmanageable.  Consequently 
the  METCAST  Channels  server  must  be  modified  to  allow 
additional  attributes  to  be  associated  with  each  product 
type  and  each  Channel  must  be  able  to  hold  multiple 
products  with  unlimited  attributes. 
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C .  OTSR 

1 .  Background 

OTSR,  which  is  operated  by  the  Regional  Centers  in 
Norfolk,  VA;  San  Diego,  CA;  and  Yokosuka,  Japan  is  a 

program  used  by  the  Navy  for  storm  avoidance  and  cost 
savings  during  long  ocean  basin  transits.  OTSR  is  an 
advisory  program,  which  minimizes  damage  to  both  personnel 
and  material  by  constantly  monitoring  the  atmospheric  and 
oceanographic  conditions  throughout  the  world' s  oceans  and 
providing  continuous  support  to  Naval,  U.S.  Coast  Guard, 
DoD  support  and  contract  vessels,  as  well  as  authorized 
foreign  vessels. 

In  order  to  maintain  an  OTSR  program,  a  center  must 

have  a  way  to  send  and  retrieve  message  traffic,  retrieve 
and  view  current  weather  data,  track  the  requested  support, 
and  supply  the  latest  support  metrics  to  the  appropriate 
commanders.  Every  center  can  send  and  retrieve  message 
traffic  either  by  using  Gateguard  or  the  Defense  Message 
Dissemination  System  (DMDS).  Additionally,  all  centers 

display  weather  data  using  JMV  and  retrieve  their  data 
either  using  METCAST  or  by  downloading  thumbnails  from  the 
FNMOC  website  (NIPRNET  or  SIPRNET) .  Today,  differences 
exist  in  the  tracking  mechanism  and  metrics  generation 
between  the  three  OTSR  centers.  Each  center  maintains  its 
own  independent  program,  using  its  own  methods  of  tracking 
(database,  spreadsheet,  etc.)  and  watch-to-watch  turnover 

procedures.  However,  all  centers  use  OTSR  folders  to  track 
routing  information  for  each  vessel.  These  folders  are 
usually  maintained  by  the  OTSR  officer  or  tech  and  contain 
some,  if  not  all  of  the  following  information: 
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1.  Ships  OTSR  request  message  or  MOVREP 

2.  Picture  of  the  ships  track  (usually  plotted  from 

JMV) 

3.  Observational  messages 

4.  Forecast  messages  (WEAX  or  AVWEAX) 

5.  OTSR  messages  (Surveillance,  Advisories,  Divert 
messages ) 


6.  Operational  messages  (OPREPS,  Towing  Reports, 
SITREPS) 

7.  Any  other  pertinent  information  about  the  vessel 


Since  OTSR  support  is  provided  on  a  daily  bases,  and 
information  is  passed  from  watch  to  watch,  a  database  or 
spreadsheet  is  maintained  to  track  the  latest  information 
on  the  ships  and  provide  turnover  between  watch  sections. 
Metrics  are  provided  in  many  different  formats  such  as 
spreadsheets  and  PowerPoint  presentations.  Some  centers 
provide  web  pages  with  tracking  information  but 
unfortunately  no  consistent  standard  exists. 

2 .  Deficiencies 

Vessel  tracking  and  metrics  collection  mechanisms 
differ  from  center  to  center.  Database  systems  which,  track 
the  current  support  need  to  be  more  robust  to  provide 
latest  ship  information  like  observations,  operational 
messages,  WEAX/AVWEAX  messages  and  all  required  message, 
graphics  and  current  statistics.  This  information  should  be 
provided  to  appropriate  commanders  in  an  easy  to  read, 
standard  format  using  an  external  or  internal  website. 
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III.  SOFTWARE  DEVELOPMENT,  OPERATING  PROCEDURES 
AND  PRODUCT  DISTRIBUTION  OVERVIEW 


This  chapter  describes  the  upgraded  features  of  JMV 
and  METCAST  and  the  Message  Parsing  Program  and  Electronic 
Ship  Folder  Database.  Detailed  information  about  the 
function  of  the  entire  system  will  be  provided  in  Chapter 
IV. 

A.  JMV/METCAST  UPGRADES 

JMV  is  a  forecaster  tool  used  by  nearly  every  Navy 
forecaster,  around  the  globe.  New  requirements  are 
continually  satisfied  as  enhancements  are  added  to  the 
program.  A  goal  of  this  thesis  was  to  improve  the 
interoperability  of  tactical  and  non-tactical  products 
created  using  JMV  and  dissemination  of  those  products  using 
METCAST.  The  concept  of  operations  (CONOPS)  for  this  effort 
concentrated  on  two  products,  HWD's  and  Ship  Tracks. 
The  concept  proven  here  can  be  applied  to  any  METOC 
product . 

1 .  JMV  Upgrades 

Over  a  six-month  period,  modifications  to  JMV  3.6  were 
made  to  make  products  more  tactically  relevant  and  to 
enable  easier  transfer  of  these  products  to  customers. 
Additionally,  changes  were  made  to  the  slide  show  feature 
of  JMV  to  allow  ship  tracks  to  be  automatically  generated 
and  available  for  web  publishing. 

a.  HWD  and  Ship  Track  Creation/Publishing 

The  primary  change  to  JMV/METCAST  was  the  ability 
to  create  and  publish  products  to  a  METCAST  channel.  For 
this  implementation,  we  used  a  METCAST  server  on  SIPRNET 
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located  at  FNMOC .  A  user-friendly  interface  was  developed 
that  allows  users  to  create  and  publish  JMV  overlays. 
Interfaces  for  publishing  finished  products  were  added  to 
the  existing  HWD's  and  Ship  Route  portions  of  JMV.  Since 
the  interfaces  remained  essentially  the  same,  very  little 
training  is  needed  to  exploit  this  new  functionality. 
Forecasters  use  the  same  drawing  tools  they  already  use 
daily  to  create  HWD's,  High  Winds  Warnings,  and  High  Seas 
Warnings  and  now  can  publish  the  product  using  the  new 
publish  capability.  Products  are  created  using  JMV 

graphical  tools  that  allow  a  user  to  draw  a  feature  and 
then  save  the  product  (See  Figure  1) . 


Figure  1 :  Saving  a  Drawing  in  JMV 

If  a  user  wants  to  publish  a  product  to  a  METCAST 
Server,  products  are  created  in  the  same  way  but  the  user 
selects  the  Publish  Drawing  option  (see  Figure  2) . 
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Figure  2:  Publishing  a  Drawing  in  JMV 

Product  attributes  must  be  specified  when  you  publish  to 
provide  database  cataloging  and  product  selection  for 
subscribers.  The  significance  of  attributes  in  METCAST 
channels  will  be  discussed  later.  Figures  3  and  4  show 
dialogs  used  to  collect  the  required  attribute  data.  The 
attributes  are  then  automatically  sent  to  the  channel  using 
a  utility  program  called  wshove.exe. 


17 


PuTiLib-li  Dj-jwinulo  METCAST  Chaiuml  (1  uf2) 


s 


Figure  3:  Publishing  Dialog  Box  1  of  2 


Figure  4:  Publishing  Dialog  Box  2  of  2 

Ship  Track  data  is  added  to  the  server  in  a 
similar  manner,  however,  rather  than  the  publish  feature 
being  added  under  the  File  menu,  it  is  added  directly  to 
the  ship  route  editor.  Users  publish  a  ship  track  to  the 
server  by  first  selecting  the  track  in  the  ship  route 
editor  and  pushing  the  publish  button.  Dialog  boxes  are 
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similar  to  those  for  HWD's.  Figures  5  through  7  show  the 
steps  required  to  submit  a  ship  track  to  the  server. 
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Figure  5:  Ship  Track  Publisher 


Figure  6: 


Ship  Track  Publish  Dialog  1  of  2 
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Figure  7 :  Ship  Track  Publish  Dialog  2  of  2 

Once  the  file  is  placed  on  the  server  it  is 
available  to  the  METCAST  client  for  download.  Products  are 
formatted  in  XML  and  comply  with  the  Task  Force  Web  Portal 
initiative.  XML  is  well  suited  for  making  the  product 
interoperable  with  other  systems.  More  discussion  about  how 
the  data  is  retrieved  from  the  server  will  be  provided  in 
the  METCAST  server  and  client  sections. 

b.  Automatic  Product  Generation 

The  upgrades  to  the  existing  slide  show  builder 
will  reduce  the  amount  of  man-hours  required  to  build 
customized  value  added  products.  Although  JMV  was  able  to 
produce  slides  using  METCAST  data  along  with  the  value 
added  products,  locally  generated  products  do  not  cause  the 
slide  show  product  to  automatically  update.  This  issue 
was  solved  for  ship  tracks  by  modifying  JMV' s  slide  show 
capability.  Now  whenever  a  ship  track  is  opened  in  the  Ship 
Route  Editor,  the  presentation  will  be  updated.  This 
feature  will  be  added  to  the  other  value  added  products 
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like  HWD '  s  in  the  near  future.  For  more  information  on 
creating  slide  show  see  FNMOC,  JMV  3.5  Help. 

2 .  METCAST  Upgrades 

a .  METCAST  Server 

The  METCAST  server  is  a  publish/subscript ion  web 
service  used  to  distribute  data  via  the  World  Wide  Web. 
Using  METCAST,  a  user  can  publish  products,  define  the 
catalog  attributes,  and  delete  products  if  authorized. 
Data  consumers  use  the  METCAST  catalog  to  discover  what 
data  is  available,  and  then,  based  on  the  discovered 
content  subscribe  to  the  required  data.  Data  modified  and 
published  by  the  producer  is  then  automatically  sent  to  the 
consumer.  In  this  case,  the  METCAST  generic  channel 
capability  was  used  to  send  HWD's  and  ship  routes.  METCAST 
also  contains  fixed  channels  for  know  data  types  like 
forecast  grids,  imagery  and  observations.  The  original 

channel  architecture  only  allowed  one  product  type  or  MIME 
type  per  channel  (i.e.,  product  format;  text,  XLM,  grids, 
PowerPoint,  etc.) .  The  new  architecture  allows  a  channel 
to  contain  multiple  MIME  types  and  an  unlimited  number  of 
descriptive  attributes.  Queries  are  made  based  on  desired 
attributes  or,  if  desired,  a  user  can  request  contents  of 
the  entire  channel.  With  this  version  of  METCAST  channels, 
nearly  unlimited  customization  is  possible  for  any 
arbitrary  data.  METCAST  channels  provide  a  very  flexible 
and  arbitrary  data  publish/subscript ion  service.  In  any 
given  implementation,  a  concept  of  operation  is  required  if 
users  are  to  exercise  this  capability.  In  our  case 
approximately  20-30  different  channels  were  established  for 
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similar  data  formats.  For  additional  information  on  the 
METCAST  Channels  Server  see  the  documentation  at 
http : / / www . met net . navy . mil/~spawar/ JMV-TNG/Metcast- 
Channels . html . 

b.  METCAST  Client 

The  METCAST  Client  provides  a  user  interface  to 
the  METCAST  Server  (Figure  8)  .  Using  the  METCAST  client 

users  can  retrieve  available  products  from  channels. 
METCAST  provides  several  Graphical  User  Interfaces  (GUI) 
specifically  designed  for  grids,  observations  and  images. 
For  channels  a  more  generic  Graphical  User  Interface  (GUI) 
was  developed.  To  access  the  Channels  dialog  box,  click  on 
Options  and  then  Channels  menus  with  the  METCAST  Client 

(See  Figures  8  and  9)  .  Select  the  Channels  option  and  an 

interface  (Figure  10)  opens  that  allows  you  to  select  the 
channel  associated  with  a  product.  HWD's  are  stored  in  the 
annotated  product  display  channel  and  the  ship  tracks  are 
stored  on  the  ship  route  channel  (classified  and 

unclassified  servers) .  When  a  user  accesses  a  channel, 
they  have  the  option  to  retrieve  the  entire  channel  or  only 
retrieve  information  based  on  a  certain  search  criteria. 
The  criteria  that  is  used  for  the  search  is  based  on  the 
attributes  associated  with  each  product.  Again,  the 

attributes  are  determined  when  the  product  is  created  and 
uploaded.  METCAST  attributes  can  be  either  mandatory  or 
optional  but  for  the  HWD's  and  ship  route  products,  all 
attributes  are  mandatory.  Figures  10  through  13  shows  how 
a  user  selects  the  available  channel,  the  required 
attribute  type  and  the  specific  attribute  value.  Once 
complete  the  user  is  ready  to  retrieve  the  product.  Each 
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retrieval  can  be  scheduled  for  an  on  demanded,  periodic  or 
scheduled  download  (see  FNMOC,  JMV  3.5  Online  Help  for 
specifics) .  When  channel  products  are  downloaded,  they  are 
routed  to  MIME  handlers  specified  in  the  mailcap  file. 
This  process  is  part  of  the  http  protocol  and  specified  by 
Borenstein,  1993. 

Mail  handlers  are  also  referred  to  in  the  METCAST 
documentation  at  http://zowie.metnet.navy.mil/~spawar/ 
Brief s/ Jmv-tng/HTTP-Ref . html .  Based  on  these  mechanisms, 
HWD '  s  are  placed  in  the  \ jmvwin\noddsf ls\globalhwd 
directory  and  the  ship  routes  are  placed  in  the 
\ jmvwin\noddsf ls\tracks  directory.  To  display  the  product 
in  JMV,  follow  the  procedures  for  displaying  a  drawing  or 
ship  route,  respectively  in  FNMOC,  JMV  3.5  Online  Help. 


r*  imuXmm  f...  4— 


Figure  8:  METCAST  Client  Interface 
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Figure  1 0 : 


METCAST  Channels  Dialog  Box 


24 


r-  HWr'IW.' 

I  


~  Jtinn  khi  a:li  '  _ ji 


iMHt  |  "bCll 


Figure  1 1 : 


Select  Product  from  Channels  by  Searching 
Attributes 


Figure  12 : 


Select  Required  Value 


from  Attribute 
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Figure  13:  Retriever  Setup 

3.  Tactical  Products 

Another  significant  addition  made  to  JMV  was  an 
ability  to  export  JMV  products  in  ESRI's  shape  format. 
Shape  allows  different  types  of  geo-referenced  data  to  be 
added  to  a  common  map  background.  ESRI  provides 

Geographical  Information  Systems  (GIS)  mapping  Services  for 
numerous  governments  and  commercial  agencies  worldwide.  In 
the  summer  of  2002,  ESRI  was  awarded  a  contract  for  the 
Commercial  Joint  Mapping  Toolkit ( C / JMTK)  that  can  be  used 
to  overlay  military  data  over  NIMA  maps.  Using  this 

capability,  the  METOC  community  can  now  feed  meteorological 
and  oceanographic  data  directly  onto  decision  makers 
displays . 

In  this  demonstration,  the  user  must  export  an  XML 
file  that  is  then  converted  to  a  Shape  file  using  a  stand 
alone  program.  This  conversion  process  is  either  spawned 
automatically  using  a  MIME  helper  application  or  manually 
from  a  command  line.  In  the  future,  we  should  incorporate 
the  export  shape  capability  directly  into  the  JMV 
interface.  The  program  is  activated  manually  as  follows; 
open  a  Windows  command  window  (Figure  14)  and  change  the 
directory  to  drive : \jmvwin\noddsfls\globalhwd.  Type  the 
command  xm!2shape  "filename". xml,  where  filename  is  the 
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actual  name  of  the  xml  HWD  file.  The  xml2shape.exe  makes 
up  three  files,  the  first  file  (.shp)  contains  the  latitude 
and  longitude  of  the  points,  lines  and  polygons  that  will 
be  generated,  a  second  file  ( .  shx)  gives  an  index  to  the 
shp  file  and  the  third  files  (.dbf)  is  the  database  file 
that  contains  the  attributes  associated  with  each  of  the 
shp  files.  Since  each  graphic  is  created  from  both  lines 
and  polygons,  the  A  files  contain  the  line  data  and  the  B 
files  contain  the  polygon  information.  JMV/METCAST  moves 
the  files  into  the  \  jmvwin\noddsf  is  directory.  The  user 
opens  the  JMV  display  map  and  then  opens  the  shape  file  by 
selecting  "File",  "Open  Shape  File  List"  from  the  menu.  A 
dialog  allows  users  to  select  the  appropriate  shape  file 
which  is  then  displayed  on  the  map  background.  The  shape 
files  are  black  and  white  because  ESRI  assigns  arbitrary 
color  files  when  initially  loaded.  A  second  file  (ARCVIEW 
3.2,.avl  file)  is  required  to  associate  colors  to  the  shape 
file  if  colors  in  ARC  View  are  desired.  Until  the  format 
of  this  file  is  better  understood,  the  current  xml2shape 
file  is  unable  to  generate  this  file.  These  files  can  be 
created  manually  within  any  of  the  ARC  products  and 
associated  to  an  HWD  or  ship  route  file. 
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Figure  14:  Activating  XML2Shape.exe  through  Command 

Prompt 


In  addition  to  shape,  XML  (Extensible  Markup  Language 
-  a  standard  format  for  the  web  enabled  Navy)  formatted  HWD 
and  ship  route  files  are  uploaded  to  the  METCAST  Channels. 
XML  files  can  be  displayed  by  the  Polexis  XIS  Viewpoint 
software  and  newer  version  of  ESRI  Arc  View.  These 
functions  are  currently  undergoing  testing  as  part  of  the 
Geospatial  Enhanced  METOC  (GEM)  program  in  San  Diego. 
Polexis  provides  encoders  and  decoders  needed  to  fuse  METOC 
data  into  the  U.S.  Navy's  COP. 

B.  MESSAGE  PARSING  PROGRAM 

The  Message  Parsing  Program  scans  incoming  text 
formatted  messages  and,  based  on  a  search  word  hierarchy 
and  user  preferences,  parses  messages  into  an  Access 
database  for  the  Electronic  Ship  Folders,  JMV  formatted 
Observations  and  MOVREPS,  and  moves  messages  to  a  specified 
directory  if  required. 

1.  Program  Requirements 

The  program  is  written  in  Visual  Basic  and  runs  on 
Windows  2000  or  higher.  The  program  is  called  parser.exe 
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and  requires  two  text  files,  plist.dat  and  activeship.txt, 
that  are  located  in  the  program  home  directory.  Two 
additional  files,  parsedata.dat  and  admin.dat,  are  created 
during  setup  and  provide  the  necessary  search  criteria  and 
configuration  data. 

2 .  Program  File  Descriptions 


The  parser.exe  file  is  the  executable  program  of  the 
Message  Parsing  Program.  This  program  parses  the  available 
message  traffic  into  the  specified  formats.  In  order  for 


the  program 

to  work 

,  several 

secondary  files  are  used 

to 

provide  the 

search 

criteria. 

locations  of  the 

available 

directories , 

port  list,  and 

the  name  and  route 

number 

of 

the  OTSR  supported 

vessels . 

The  following  is 

a  list 

of 

required  files  and  a  description  of  their  operation: 

1.  activeship.txt:  The  activeship.txt  file  is 
created  in  order  to  connect  the  messages  sorted  by  the 
parser  program  with  the  ships  being  supported  in  the 
Electronic  Ship  Folder.  This  file  is  exported  by  the 
database  with  the  route  number  and  ship  name  separated  by  a 
comma  (Ex.  S2002100,  USS  Shipname)  .  The  format  for  the 
route  number  is  Station  Letter  (S  =  San  Diego,  N  =  Norfolk 
and  Y  =  Yokosuka)  followed  by  the  four-value  year  and 
finally  the  sequential  route  number  (numbers  start  at  1  at 
the  beginning  of  each  calendar  year)  . 

2.  plist.dat:  The  plist.dat  file  contains  all  the 
ports  around  the  world,  along  with  the  associated  latitude 
and  longitude.  This  file  is  used  when  a  MOVREP  is  parsed 
and  the  ETA  or  ETD  line  of  the  message  does  not  contain  the 
latitude  and  longitude  information. 

3.  parsedata.dat:  The  parsedata.dat  file,  created  by 
the  parser.exe  file,  contains  the  search  parameters  and 
parsing  criteria.  This  file  is  created  when  the  program  is 
installed  and  initialized  with  the  first  search  parameter. 
The  file  is  a  random  access  file  or  indexed  file  that 
allows  the  information  within  the  file  to  be  quickly 
accessed  and  read  into  and  out  of  the  user  interface.  A 
text  editor  should  never  be  used  to  manually  edit  this 
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file,  as  this  will  make  the  file  unusable  by  the  Message 
Parsing  Program. 

4.  admin.dat:  The  admin.dat  file  contains  the 
configuration  data  for  the  program.  The  configuration  data 
holds  the  command  name,  command  location,  and  all  the 
directories  for  the  parsed  data  files.  These  directories 
can  all  be  pointed  to  the  same  location  or  to  different 
locations  depending  on  how  the  administrator  of  the  program 
wishes  the  files  to  be  stored. 

5.  p_log.dat:  The  p_log.dat  file  is  a  log  that 
contains  the  actions  of  the  program  as  it  scans  each  file. 
The  following  data  is  stored  in  the  log  file: 

A.  Time  of  scan 

B.  Original  file  name 

C.  Ship  Name 

D.  Date-Time-Group  of  Message 

E.  Logcode .  The  logcode  is  a  string  of 
characters  that  show  all  the  various  steps  that  the  program 
took  to  parse  the  file,  as  well  as  any  problems  that  may 
have  occurred.  The  possible  messages  are: 

1.  Parsed  to  Database.  This  means  that  the 
data  within  the  file  was  parsed  into  the  Electronic  Ship 
Folder  format  and  was  placed  in  the  mess.txt  file. 

2.  Failed  to  Parse  JMV  File,  the  file  is  in 
strDir,  where  strDir  is  the  directory  where  the  file  was 
placed.  This  error  occurs  when  too  many  missing  variables 
were  detected  when  the  observation  or  MOVREP  files  were 
parsed.  The  file  is  moved  to  a  temp  directory  and  can  be 
modified  by  the  user  and  reprocessed. 

3.  MOVREP  Parsed  to  JMV.  The  MOVREP  was 
properly  parsed  into  the  JMV  format  and  the  file  was  copied 
into  the  specified  JMV  directory  and  named 
SHIPNAME_DTG.  shp,  where  SHIPNAME  is  the  name  of  the 
originator  of  the  message  and  DTG  is  the  date-time-group  of 
the  message.  It  is  recommended  that  all  ship  routes  be 
sent  to  the  tracks  directory  within  your  primary 
jmvwin\noddsf is  directory. 

4.  MOVREP  not  parsed,  ETD ,  ETA,  VIA,  POS  or 
MODLOC  not  found.  This  error  occurs  when  a  MOVREP  file  is 
parsed  and  neither  the  ETD,  ETA,  VIA,  POS  or  MODLOC  key 
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words  are  found.  Usually,  when  this  occurs  the  MOVREP  is 
an  arrival  or  update  message  and  would  not  need  to  be 
placed  into  JMV. 

5.  OB  not  parsed.  Missing  99.  This  error 
occurs  when  the  99  specifying  the  location  of  the  latitude 
group  is  missing  from  the  observation.  If  the  99  is 
missing  than  the  parser  cannot  locate  the  different 
sections  of  the  code  since  it  is  using  the  99  to  determine 
where  the  information  should  be  located  within  the  code. 
In  some  case  the  99  may  be  in  the  message,  however  extra 
spaces  may  be  between  the  Latitude  group  and  the  previous 
code  group. 

6.  OB  parsed  to  JMV.  The  observation  was 
properly  parsed  into  the  file  jmvobs.dat  located  in  the 
specified  JMV  Directory. 

7.  File  moved  to  strDir,  where  strDir  is 
the  name  of  the  directory  where  the  file  was  placed. 

8 .  Search  Phrase  provides  the  key  word  that 
was  found  in  the  message. 

9.  No  search  phrase  found,  file  moved  to 
General  Folder.  This  message  means  that  none  of  the  search 
words  in  the  parsedata.dat  file  where  found  in  the  message 
and  now  the  program  has  defaulted  to  move  the  message  in  to 
the  database  as  general  and  the  text  file  has  been  moved  to 
the  general  folder. 

F.  Code  for  whether  search  parameter  was  found 
(1  =  yes,  0  =  no) 

6.  Mess.txt:  The  mess.txt  file  is  the  message  export 
file,  which  is  read  into  the  Electronic  Ship  Folder.  This 
file  is  generated  when  the  messages  are  parsed.  When  the 
file  is  read  into  the  database,  this  file  is  deleted  and 
recreated  by  parser.exe. 

3 .  Installation 

The  Message  Parsing  Program  (Fig.  15)  operates  in 
conjunction  with  the  Electronic  Ship  Folder  Database  and 
both  programs  should  be  placed  in  the  same  directory  for 
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easy  operation.  Directory  selection  is  dependent  on  user 
preference  and  can  be  used  in  stand  along  mode  on  a  single 
computer  or  stored  on  a  network  drive.  Although  the 
database  is  designed  to  be  accessed  by  multiple  users,  the 
Message  Parsing  Program  should  be  utilized  by  one  computer 
system  at  a  time  (i.e.,  OTSR  Router  or  Tech  computers) .  To 
install  the  Message  Parsing  Program,  add  the  parser.exe  and 
plist.dat  file  in  your  directory  and  then  export  the  list 
of  active  ships  from  the  database  (see  Electronic  Ship 
Folder  Database,  Program  Operation)  . 


Figure  15:  Message  Parsing  Program  User  Interface 

4 .  Description  of  User  Interface 

Once  the  program  is  installed  and  all  required  files 
are  available,  the  program  can  be  run  by  double  clicking  on 
the  parser.exe  file.  The  user  interface  shown  in  Figure  15 
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is  the  primary  screen  of  the  Message  Parsing  program.  In 
order  to  understand  how  data  should  be  entered  into  this 
form  one  will  need  to  understand  the  purpose  of  each  of  the 
sections . 

a .  Program  Header 

Figure  16  shows  the  program  header  where  users 
must  decide  what  term  the  program  will  look  for  and  what 
will  be  done  to  the  message  once  that  particular  term  is 
found.  The  first  object  of  the  form  is  the  "Select  Profile 
Name"  drop-down  list.  From  the  drop-down  list  the  user  can 
view  all  the  Profile  Names  for  each  of  the  search  phrases. 
Each  profile  can  be  viewed  by  selecting  the  appropriate 
item  from  the  drop-down  list. 

The  "Profile  Name"  is  a  unique  identifier  of  the 
search  phrase  being  looked  for.  Since  the  search  phrase 
may  not  be  unique  if  "Secondary  Selection  Criteria"  is  also 
being  used,  the  profile  name  must  be  something  that  helps 
the  user  remembers  what  the  particular  profile  does.  If 
users  enter  two  of  the  same  profile  names,  an  error  will  be 
produced  and  the  user  will  need  to  change  the  name  before 
the  profile  will  be  saved. 

The  "Search  Phrase"  is  the  exact  term  that  will 
be  scanned  for  in  the  message.  Since  the  term  must  be  an 
exact  match  to  the  string  found  in  the  messages,  in  order 
for  the  message  to  be  parsed,  users  may  need  to  use  several 
forms  of  the  same  string  idea  to  get  all  the  associated 
messages  (e.g.,  SURFACE  OBSERVATION,  SURFACE  OB,  SURF  OB, 
SRF  OB)  .  In  order  to  create  these  different  phrases, 
several  profiles  will  need  to  be  created  with  unique 
profile  names  for  each. 
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The  last  object  in  the  header  is  the  "Parsing 
option"  box.  This  box  controls  what  features  are  available 
for  data  entry.  If  the  user  selects  one  or  all  of  the 
available  check  boxes  then  the  dialogs  below  the  header 
will  become  enabled.  In  the  parsing  options  box,  users 
have  the  option  to  move  the  file,  parse  the  message  to  the 
database,  parse  the  message  to  JMV  or  add  a  secondary 
selection  criteria. 


Figure  16:  Message  Parsing  Program  Header 

b.  Buttonology 

As  seen  in  Figure  15,  there  are  several  buttons 
along  the  right-hand  side  of  the  program  that  allow  the 
user  to  Add  Profile,  Edit  Profile,  Copy  Profile,  Remove 
Profile,  Save  Profile,  Exit,  Edit  Admin  and  Parse  Messages. 
Depending  on  the  current  action  that  the  user  is  trying  to 
perform,  some  or  all  of  the  buttons  may  be  available  for 
the  user  to  select.  The  meanings  of  each  of  the  buttons 
are  self-explanatory,  however  the  method  for  adding  or 
editing  a  profile  is  not  necessarily  so.  When  the  program 
is  initially  opened  the  program  window  will  look  like 
Figure  15  with  most  of  the  screen  disabled,  the  text  boxes 
blank  and  the  objects  under  the  header  locked.  This 
ensures  that  the  profiles  will  not  be  changed  accidentally. 
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If  a  users  wishes  to  view  the  list  of  profile  names  then 
they  can  select  the  drop-down  list  and  click  on  the 
appropriate  profile  name.  Once  the  profile  is  selected  the 
information  stored  for  that  profile  will  be  visible, 
however  the  boxes  will  remain  disabled  and  locked.  If  the 
user  wishes  to  change  the  profile,  the  Edit  Profile  button 
should  be  selected  and  then  all  objects  that  have  checks  in 
the  header  will  be  enabled  and  unlocked  (Fig.  17) .  If  the 
Profile  Option  in  the  header  is  not  selected,  then  the 
associated  box  below  the  header  will  not  be  enabled. 


Figure  17:  Example  of  an  Editable  Profile 

c.  Entering  Data  into  the  Move  File  Frame 

The  Move  File  frame  (Fig.  18)  is  where  the  user 
can  specify  where  a  parsed  message  should  be  moved  to  and 
how  the  file  should  be  named.  Depending  on  the  message 
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type,  different  pieces  of  information  may  be  available  from 
the  message  itself  or  the  activeship.txt  file,  which  can  be 
attached  to  the  filename  to  help  make  the  file  more 
identifiable  than  just  using  a  standard  naming  convention. 
The  move  file  frame  interface  provides  the  text  box  to 
enter  a  directory  name  and  then  provides  two  methods  to 
specify  the  filename.  If  the  user  selects  Preformatted, 
the  filename  will  be  created  by  selecting  from  the  list  of 
available  options.  Using  this  method,  the  user  can  create 
either  a  dynamic  filename  that  is  unique  for  every  message 
or  a  static  filename  that  will  overwrite  every  time  a  new 
message  is  received.  If  the  user  selects  Manual,  then  the 
user  can  type  in  the  filename  that  will  overwrite  any 
previous  message.  For  either  choice,  if  the  message  is 
also  parsed  to  the  database,  a  copy  of  the  original  message 
will  be  saved  in  the  database. 
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Figure  1 8 : 


d.  Required  Header  Info 


The  "Required  Header 

Info" 

frame 

(Fig. 

19) 

is 

used  to  determine  whether 

the 

ship 

name 

should 

be 

the 

Originator  or  the  Addressee 

(ADDE) . 

In  the  case 

of 

an 

observation,  the  Originator 

of 

the 

message 

would 

be 

the 

ship  name.  However,  if  the  message  were  a  weather  forecast 
message  (WEAX)  to  an  individual  ship,  then  the  ADDE  would 
be  the  ship  name.  When  a  message  is  parsed  the  information 
created  from  this  field  is  used  to  determine  the  vessel's 
name  and  compares  that  to  the  activeship  file  to  see  if 
that  vessel  is  being  supported.  If  the  vessel  is  being 
supported  and  route  number  was  selected  to  be  part  of  the 
filename,  then  the  route  number  is  inserted  into  the 
filename . 


Required  Header  Info - 1 

Is  fhe  Ship  Name  the  Originator  or  Adde? 

C  Originator 
C  Adde 

Figure  19:  Required  Header  Frame 

e .  Database  Frame 

The  Database  frame  (Fig.  20)  is  used  to  clarify 

what  database  message  type  the  file  should  be  added  to,  if 

the  file  should  always  be  saved  in  the  specified  "Move" 

directory  and  finally  provides  the  starting  and  ending 

string  that  forms  the  information  which  is  added  to  the 

database.  The  six  message  types  equate  to  the  six  database 

types  in  Figure  20.  The  yes  check  box  provides  the  user  the 
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ability  to  move  messages  from  ships,  not  currently  being 
supported,  to  a  different  director  from  those  that  are 
being  supported.  If  this  box  is  selected  than  messages 
from  vessels  not  being  supported  will  be  moved  to  the 
External  Message  directory.  This  helps  to  separate  the 
vessels  that  are  in  the  AOR  with  vessels  that  are  outside 
the  AOR.  Finally,  the  First  Search  String  and  Last  Search 
String  provide  the  key  words  that  cause  the  parser  to  parse 
out  the  required  text  string  from  the  message.  In  most 
cases,  the  first  search  string  should  be  the  search  phrase 
you  are  looking  for,  but  in  some  cases  another  string  my  do 
better.  If  the  first  search  string  is  not  the  same  as  the 
search  phrase,  the  first  search  string  must  follow  the 
search  phrase  in  the  message.  If  the  first  search  string 
precedes  the  search  phrase  then  the  text  will  never  be 
found  and  the  message  will  not  parse. 
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Figure  20:  Database  Frame 
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f .  JMV  Frame 

The  JMV  frame  (Fig.  21)  provides  the  JMV  format 
that  the  message  will  be  parsed  into.  Currently  the  parser 
only  supports  MOVREP' s  and  BBXX  formatted  messages,  however 
future  versions  of  this  program  or  others  like  it  should  be 
able  to  parse  OTSR  Requests  and  observations  that  do  not 
contain  the  BBXX  label.  When  parsing  either  a  MOVREP  or  a 
BBXX  message,  select  the  appropriate  JMV  selection  and  then 
provide  a  directory  string  for  where  the  files  should  be 
placed.  All  MOVREP  files  are  placed  in  the  appropriate 
directory  with  a  shipname_dtg . shp  format  where  shipname  is 
the  name  of  the  vessel  and  dtg  is  the  date-time-group  of 
the  message.  Observations  are  place  into  the  appropriate 
directory  and  combined  into  one  file  called  jmvobs.dat. 
Because  JMV  has  separated  Sea  Synoptic  files  for  every  area 
that  is  created  within  JMV,  the  jmvobs.dat  file  will  need 
to  be  manually  appended  to  the  SEA  SYNOPTIC 
REPORTAOSAAAAA0ANASA . JMV  file,  located  in  the  directory  of 
the  area  one  is  using  whenever  the  latest  observations  are 
needed.  If  a  user  does  not  know  what  area  they  are  using 
from  JMV,  the  area  name  is  located  in  the  top  left  hand 
corner  of  the  JMV  display  screen  (Fig.  22)  that  they  use  to 
display  JMV  products. 
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Figure  21:  JMV  Parsing  Frame 
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Figure  22 : 


JMV  Map  Display  Screen  for  Area  NEWPAC 
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5 .  Adding  Configuration  and  Parsing  Criteria 

Once  the  parser.exe,  plist.dat  and  activeship.txt  are 
all  placed  in  the  designated  directory,  the  program  is 
ready  to  be  initialized  by  adding  configuration  data.  To 
add  configuration  data,  click  on  the  button  labeled  "Edit 
Admin"  (see  Fig.  15)  to  open  the  administration  form  (Fig. 
23)  .  Once  in  the  administration  form  is  open,  enter  the 
command  name  and  Location.  Enter  this  information  in  the 
same  format  as  the  commands  Plain  Language  Address  (PLA) . 
Next,  enter  the  directory  locations  were  the  individual 
messages  would  be  stored  once  they  are  processed.  These 
directories  can  all  be  the  same  path  or  different  paths  as 
shown  in  Figure  23.  While  entering  the  directories  into  the 
administration  form,  ensure  that  all  directory  paths  end 
with  the  "\".  Error  checking  is  installed  to  ensure  that 
the  path  contains  this  slash,  however,  as  a  general  rule 
all  paths  should  end  with  a  slash. 
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Figure  23:  Form  Used  to  Enter  Configuration  Data 


Now  that  the  configuration  data  is  added,  it  is  time 
to  beginning  adding  the  parsing  criteria.  Since  a  method 
of  prioritizing  the  criteria  is  not  available  for  this 
version  of  the  program,  care  and  planning  should  be  given 
to  the  order  that  each  criterion  is  added.  As  a  general 
rule,  priority  should  be  given  in  the  following  order: 

1.  Individual  search  terms  that  will  be  received  from 
vessels  (e.g.,  BBXX,  Surface  Ob,  OTSR  Request,  OTSR  Report, 
etc . ) 


2 .  Individual  search  terms  with  secondary  search 
criterion  set  for  your  command. 

3.  Individual  search  terms  with  secondary  search 
criterion  set  for  other  commands.  If  you  have  a  priority 
for  other  commands,  place  the  commands  with  the  highest 
priority  higher  in  the  list. 
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As  an  example  of  how  this  list  should  be  prepared,  the 
following  short  list  would  be  for  NPMOC  San  Diego. 

1 .  BBXX 

2 .  SURFACE  OB 

3 .  SURF  OB 

4 .  WEATHER  OB 

5 .  WX  OB 

6 .  MOVREP 

7 .  MOVEREP 

8.  WEAX  FOR,  SECONDARY:  NAVPACMETOCCEN  SAN  DIEGO  CA 

9.  WEAX  UPDATE  FOR,  SECONDARY:  NAVPACMETOCCEN  SAN 
DIEGO  CA 

10.  WEAX  FOR,  SECONDARY:  NAVPACMETOCCEN  YOKOSUKA  JA 

11.  WEAX  UPDATE  FOR,  SECONDARY:  NAVPACMETOCCEN 
YOKOSUKA  JA 

12.  TROPICAL  CYCLONE,  SECONDARY:  NAVPACMETOCCEN  PEARL 
HARBOR  HI 

Remember,  that  if  a  search  word  is  not  found  or  the 
secondary  selection  criterion  is  not  found  than  the  message 
will  be  given  a  general  message  type  and  be  parsed  into  the 
general  folder.  If  you  are  not  concerned  with  having 
another  centers  message  parsed  to  a  specific  location  or 
given  a  specific  message  type  (OBS,  OTSR,  WEAX,  OPS,  etc.), 
do  not  add  them  to  the  list. 

6 .  Program  Operation 

Once  the  configuration  and  parsing  data  have  been 
entered  into  the  system,  the  program  can  be  run  by  placing 
the  files  in  the  designated  drop  directory  and  manually 
activating  the  "Parse  Messages"  button.  Occasionally, 
errors  occur  with  a  particular  file  that  causes  the  program 
to  stop  operating.  In  most  cases  the  filename  will  appear 
in  an  error  box.  To  continue  the  parsing  process,  remove 
the  file  and  press  the  parse  messages  button  again.  Once 
the  parsing  program  is  complete  a  message  box  will  open 
telling  you  that  you  have  successfully  parsed  all  the 
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available  messages.  Click  the  OK  button  and  leave  the 
program  open  for  the  next  round  of  parsing.  Once  you  have 
completed  the  parsing  process  it  is  a  good  idea  to  go  ahead 
and  import  the  messages  into  the  database  (See  Program 
Operation  under  the  Electronic  Ship  Folder  section)  . 

C.  ELECTRONIC  SHIP  FOLDER  DATABASE 

The  Electronic  Ship  Folder  (ESF)  Database  (Fig.  24)  is 
designed  to  be  the  one  stop  data  location  for  the  OTSR 
router.  The  database  provides  data  entry  and  access 
capability  to  customer,  support,  and  message  data. 
Additionally,  the  program  has  the  capability  to  provide 
links  to  valuable  METOC  data  such  as  satellite  images, 
overlaid  model  verification  products,  Meteograms  and  many 
other  products  which  can  be  produced  using  JMV' s  slide  show 
builder,  WSI  or  Terascan.  Once  the  support  information  has 
been  entered,  html  web  pages,  metrics  and  reports  can  be 
automatically  generated  from  the  existing  data. 


44 


Figure  24:  Electronic  Ship  Folder  Start  Form 

1.  Program  Requirements 

The  database  used  to  create  the  ESF  is  run  on  Access 
2000  and  requires  Microsoft  Windows  OS  running  Microsoft 
Office  2000  or  Microsoft  Office  XP  to  operate.  Since 
databases  have  a  tendency  to  become  very  large,  the  machine 
that  is  used  to  store  the  database  should  have  several 
hundred  MB's  of  available  storage. 

2 .  Program  File  Descriptions 

The  database  program  is  made  up  of  four  files  that  are 
responsible  for  maintaining  the  data,  controlling  the 
security  access,  providing  the  ingestible  data,  or 
containing  the  exported  data. 
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1.  ESF.mdb:  The  database  file  is  the  esf.mdb  file 
that  contains  all  the  Forms,  Tables,  Queries,  VBA  Modules 
and  Reports  that  are  used  by  the  program. 

2.  System. mdw:  The  system. mdw  file  controls  the 
security  access  to  the  program.  This  level  of  security  is 
not  meant  to  keep  people  out  of  the  database  since  the 
program  will  be  on  a  secured  network,  but  instead  to  log 
access  to  the  database. 

3.  Mess.txt:  This  file  is  created  by  the  Message 
Parsing  Program  and  contains  all  the  message  traffic  that 
has  been  received  by  the  center.  This  file  is  used  by  the 
OTSR  router  to  view  incoming  message  traffic  and  ease  data 
entry  procedures. 

4.  Activeship.txt:  Activeship.txt  is  exported  from 
the  database  once  some  data  has  been  entered  into  the 
system  and  ships  are  under  active  support  from  the  OTSR 
Center . 

3 .  Installation 

To  install  the  ESF  program,  copy  the  esf.mdb  and 
system. mdw  files  into  the  same  directory  where  the 
parser.exe  file  was  copied.  Now  that  the  files  are  copied 
to  the  correct  directory,  the  security  parameters  need  to 
be  updated.  Find  wrkgadm.exe  usually  located  in  the 
C:\programfiles\Microsoftoffice\office\1003\  directory.  If 
the  file  is  not  located  in  this  directory,  run  a  search  on 
wrkgadm.exe  to  find  the  file.  Once  you  find  the  file, 
double-click  on  it  and  a  Workgroup  Administrator  window 
(Fig.  25)  will  open.  Click  on  join  to  open  the  Work  Group 
Information  file  (Fig.  26)  and  browse  to  find  the 
system. mdw  file  located  in  the  directory  with  the  ESF 
database  file.  Once  the  correct  system. mdw  file  is 
selected,  select  OK.  Figure  27  should  now  be  seen;  close 
this  window  and  press  exit  on  the  Figure  25. 


46 


Workgroup  Administrator 


Name: 

Company: 

Workgroup  E:\THESIS\SYSTEM.MDW 


Your  workgroup  is  defined  by  the  workgroup  information  file  that  is  used 
at  startup.  You  can  create  a  new  workgroup  by  creating  a  new 
information  file,  or  join  an  existing  workgroup  by  changing  the 
information  file  that  is  used  at  startup. 


Figure  25:  Microsoft  Access  Workgroup  Administrator 


Figure  26:  Workgroup  Information  File 
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Figure  27:  Workgroup  Administrator 


Now  that  the  program  is  installed  and  the  system 
settings  are  in  place,  double-click  on  esf.mdb  and  make 
sure  that  the  log  in  screen  opens  (Fig.  28)  when  the 
database  starts. 
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Figure  28:  Database  Login  Screen 

If  a  login  screen  does  not  appear  when  the  program 
starts,  repeat  the  installation  process  and  ensure  that  you 
have  not  selected  the  system. mdw  from  a  directory  other 
than  were  the  database  is  located.  Upon  initial  install  of 
the  database  the  Admin  password  is  adminl .  Before  you 
begin  to  use  the  database,  the  chosen  administrator  of  the 
database  should  change  the  Admin  login  and  add  new  logins 
for  each  member  who  will  have  access  to  the  database.  To 
complete  these  operations  follow  the  instructions  in  the 
next  section. 

4 .  Adding  or  Changing  Security  Logins 
a.  Changing  Login  Passwords 

To  change  the  administrator  (Admin)  or  any  other 

logins  password,  users  must  login  as  Admin.  Once  you  have 
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opened  the  database  and  logged  in,  click  on  Tools  on  the 
main  toolbar,  then  Security  and  finally.  User  and  Group 
Accounts  (Fig.  29) . 
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Figure  29:  Accessing  Security  Form 


Once  users  select  the  User  and  Group  Accounts,  a 
User  and  Group  Accounts  window  (Fig.  30)  will  open  showing 
the  admin  user.  If  this  is  the  first  time  using  the 
program  than  the  Admin  password  should  be  changed  so  to 
ensure  program  integrity.  To  change  the  Admin  password, 
click  on  the  "Change  Logon  Password"  and  check  to  make  sure 
that  the  User  Name  is  Admin.  If  the  user  name  is  not 
Admin,  than  the  user  is  not  logged  in  as  Admin  and  must 
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login  again  as  Admin  to  complete  the  password  change.  If 
the  username  is  Admin  then  enter  adminl  or  any  previously 
entered  password  into  the  Old  Password  text  box  and  the 
enter  the  new  password  in  the  New  Password  and  Verify 
boxes.  Click  on  the  Apply  button  and  then  select  OK.  Your 
new  password  is  now  in  effect.  To  test  the  login,  close 
the  database  and  login  again  as  Admin.  If  someone  other 
than  Admin  needs  to  have  there  password  changed  or  reset 
two  methods  can  be  used.  The  first  method  is  to  login  as 
the  user  and  then  follow  the  procedures  above  or,  method 
two  is  to  have  Admin  clear  the  password  of  the  user  by 
selecting  the  users  name  under  User  and  Name:  and  then 
click  Clear  Password.  This  will  clear  the  users  password 
and  when  they  login  they  will  only  enter  the  login  name 
without  any  password.  To  reset  the  password,  have  the  user 
open  the  User  and  Group  Accounts  window  (Fig.  29  and  30) 
and  go  to  Change  Logon  Password  and  enter  a  new  password  in 
the  New  Password  and  Verify  text  boxes. 
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Figure  30:  User  and  Group  Accounts 


Figure  31:  Changing  Admin  Login 

b.  Add  New  Login 

To  add  a  new  login  to  the  database,  login  to  the 

database  as  Admin  and  open  the  User  and  Group  Accounts 
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window  by  following  the  instructions  from  the  previous 
section.  Click  on  the  Users  tab  (Fig.  30)  of  the  window 
and  select  New  to  open  the  New  User/Group  form  (Fig.  32)  . 
Enter  the  users  name  (see  warning  below)  in  the  name  box 
and  then  enter  a  Personal  ID  value.  This  value  does  not 
need  to  be  unique;  however  the  combination  of  the  Name  and 
Personal  ID  value  must  be  unique.  Click  on  OK  and  the  new 
user  will  be  created  without  a  password  associated  with  it. 
To  add  the  password,  close  the  database  and  login  as  the 
new  user,  but  do  not  add  a  password  in  the  password  block. 
When  the  new  user  is  logged  in,  open  the  User  and  Group 
Accounts  window  and  go  to  Change  Logon  Password.  At  the 
Change  Logon  Password  window  and  verify  that  the  User  Name 
is  the  same  as  the  new  users  and  enter  the  new  password 
into  the  New  Password  and  Verify  text  boxes. 

Warning:  When  creating  a  login  and  password  only 
use  letters  (a  -  Z)  and  numbers  (0  -9) .  Do  not  use  spaces, 
slashes  or  any  other  unusual  character  as  they  may  change 
when  the  database  is  compacted  or  repaired. 


Figure  32 :  New  User/Group  Entry  Form 

5 .  Description  of  Database  Setup  and  User  Interface 

The  database  is  designed  to  reduce  redundant  data 
entry  and  allow  quick  access  to  necessary  data.  All 
queries,  forms,  reports  and  html  pages  are  built  on  the 

information,  which  is  stored  in  the  many  tables  within  the 
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database.  Figure  33  shows  the  relationship  between  the  two 
primary  tables  (Customer  and  Support)  and  the  secondary 
tables  that  provide  inputs  to  the  primary  tables. 


Figure  33:  Database  Table  Relationships 

To  fully  understand  how  the  database  operates  one  must 
understand  what  makes  up  the  database.  The  following 
sections  will  describe  the  tables,  forms  and  reports 
generated  by  the  database, 
a.  Tables 

Tables  are  the  foundation  to  any  database.  They 

hold  the  information  for  the  database,  as  well  as  provide 

the  initial  formatting  for  how  the  data  will  be  stored. 
From  Figure  33,  this  database  contains  15  separate  tables 

with  some  additional  tables  being  created  and  deleted  as 

files  are  imported  and  exported.  The  following  paragraphs 
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will  discuss  the  key  tables  and  what  they  are  used  for. 
Additionally,  any  special  relationships  between  the  tables 
and  the  impact  that  that  relationship  has  on  data  entry 
will  be  discussed. 

The  Customer  table  (Fig.  34)  contains  all  the 
permanent  and  semi-permanent  information  about  the  vessel. 
This  information  includes  the  points  of  contact,  telephone 
numbers,  e-mail  addresses,  vessel  limits,  ship 
characteristics,  vessel  manning,  operational  commanders  and 
possible  mechanical  problems  associated  with  the  vessel. 
This  information  should  be  maintained  with  the  utmost 
vigilance  since  it  is  the  table  that  will  provide  the  most 
complete  pass  down  between  the  vessel's  missions.  The 
Customer  table  has  a  one-to-many  relationship  with  the 
Support  table  that  requires  that  the  customer  entered  into 
the  Support  table  exist  in  the  Customer  Table. 
Additionally,  the  index  on  the  ship  name  is  set  so  that  not 
duplicate  entries  can  be  entered  into  the  table.  This 
requires  that  every  ship  only  be  entered  once  the  in  the 
database  and  that  its  information  be  constantly  maintained. 

The  Support  Table  (Fig.  35)  contains  all  the 
information  about  an  individual  support  mission.  Each 
record  in  the  table  will  be  given  a  mission  route  number 
(RTE )  in  order  to  provide  a  primary  identifier  between  all 
the  records  in  this  table.  Since  support  from  3  centers 
could  potentially  be  in  this  table,  every  entry  requires  a 
route  number  for  each  support  entry  and  this  route  number 
will  be  remain  the  same  even  when  vessels  is  passed  to 
another  center.  The  Support  table  has  many  relationships 
with  other  tables  that  provide  an  input  (drop-down  list  in 
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forms)  into  the  data  that  is  available  in  the  Support 
table . 
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Figure  35:  Support  Table 


The  OPCON  table,  which  feeds  the  Customer  table 
with  the  appropriate  operational  commander,  is  used  in 
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conjunction  with  the  OPCONINFO  table  (Fig.  36)  .  These  two 
tables  have  a  one-to-many  relation  where  the  OPCON  table 
provides  the  name  of  the  operational  commander  and  the 
OPCONINFO  provides  the  point  of  contacts  (POC)  name,  e-mail 
address  and  phone  number.  Since  an  OPCON  can  have  several 
POC' s  the  OPCON  needed  to  be  separated  from  the  POC  data. 
A  POC  of  an  OPCON  cannot  be  added  until  the  OPCON  is 
available  in  the  OPCON  table. 


Field  Name 

Data  Type 

Description 

OPCON 

Text 

NAME  OF  OPERATIONAL  COMMANDER 

POC 

Text 

POINT  OF  CONTACT  AT  OPCON  STAFF 

EMAIL 

Text 

EMAIL  ADDRESS  OF  OPCON  POC 

PHONE 

Text 

PHONE  NUMBER  OF  OPCON  POC 

Figure  36:  Operational  Command  Info  Table  (OPCONINFO) 

The  final  key  table  in  the  database  is  the 
SHIPLOC  table  that  contains  the  related  hyperlink  products 
based  on  the  geographic  area  of  the  customer's  position. 
Again,  a  one-to-many  relationship  was  created  between 
GEOLOCATIONS  and  SHIPLOC  to  provide  data  to  the  Support 
table.  The  GEOLOCATIONS  table  holds  the  available 
geographic  regions  that  a  vessel  can  be  in  and  the  SHIPLOC 
table  holds  the  locations  with  the  products  names  and 
hyperlink  to  the  product. 
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Figure  37:  Ship  Position  Product  Link  Table  (SHIPLOC) 
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b. 


Forms 


Forms  in  a  database  are  the  primary  means  of 
entering  data.  By  creating  useful  forms,  the  user  can 
quickly  and  easily  enter  the  necessary  information  and  make 
the  information  available  to  the  rest  of  the  command.  This 
database  has  many  forms  for  entering  the  data  into  the 
tables.  Some  forms  are  individual  forms  that  are  connected 
to  only  one  table,  however  many  of  the  forms  have  forms  and 
sub  forms  which  use  data  from  the  first  form  to  recall 
information  from  the  sub  form.  In  most  case,  where  you 
find  a  one-to-many  relationship  between  the  tables,  you 
will  also  find  a  sub  form  used  to  access  the  table  with  the 
many  relationship.  In  Figure  38,  the  sub  form  is  inside 
the  box  and  is  dependent  on  the  SHIPNAME  input  box. 

The  first  form  that  a  user  interacts  with  is  the 
startup  form  (Fig.  39)  that  controls  the  basic  navigation 
through  the  program.  From  the  startup  form  a  user  can  move 
to  the  secondary  forms  to  add  a  new  customer,  add  new 
support,  modify  existing  support,  review  incoming  messages, 
import  or  export  required  files,  view  or  print  the  turnover 
sheet,  modify  the  administration  forms  or  close  the 
database . 
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Support  Form 
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Figure  39:  Startup  Form,  Used  to  Navigate  through 

Program 


The  Add  Customer  form  (Fig.  40)  is  used  to  enter, 
view  or  modify  data  about  customers  that  either  are  or  will 
be  supported  by  OTSR.  The  primary  purpose  of  this  form  is 
to  provide  history  on  vessels  so  that  as  personnel  in  the 
OTSR  program  turnover  and  are  replaced  by  new  routers, 
information  on  how  a  vessel  were  supported  or  what  their 
standard  limits  are,  can  be  obtained.  This  form  contains 
much  of  the  standard  information  that  is  available  via  web 
pages  or  "Janes",  however  if  the  information  can  be 
retrieved  directly  from  the  customer,  the  data  is  usually 
far  more  accurate.  Almost  all  the  controls  on  the  form  are 
text  input  where  the  data  is  typed  directly  into  the  text 
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boxes.  The  only  exception  to  this  is  the  Search  by  Ship 
Name  drop-down  box  and  the  OPCON  sub  form.  The  Search  by 
Ship  Name  control  allows  the  user  to  select  the  customer 
that  they  wish  to  review.  It  also  provides  a  way  to 
quickly  view  all  the  customers  to  determine  if  a  new 
customer  needs  to  be  added.  The  OPCON  sub  form  is  used  to 
view  all  the  POC's  of  the  selected  OPCON.  To  change  the 
current  POC  use  the  navigation  bar  below  the  POC  and  PHONE 
header.  For  information  on  how  to  enter  data  into  each  of 
the  text  boxes,  select  the  box  and  then  look  in  the  lower 
left-hand  corner  of  the  screen  to  see  what  is  suppose  to  be 
in  the  box  and  what  the  format  should  be. 


uUVuKwirta'  r _ I-J I  rwri 

Figure  40:  Customer  Entry  Form 
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The  Support  Form  (Fig.  40)  is  the  primary  form 
that  a  router  or  OTSR  tech  will  use  while  working  with  the 
data  entry  portion  of  this  program.  Because  of  the 
importance  of  entering  data  correctly,  we  will  discuss  each 
of  the  controls  of  this  form  in  detail.  This  form  is  used 
for  adding,  editing  and  viewing  all  supported  customers. 
Two  versions  of  this  form  are  available  from  the  Startup 
form.  Add  New  Support  and  Open  OTSR  Support.  The  Add  New 
Support  opens  the  form  to  a  new  record  and  the  Open  OTSR 
Support  opens  the  form  to  the  first  record.  Once  you  have 
opened  the  OTSR  support  form,  new  support  can  be  added  by 
clicking  on  the  Add  New  Support  button  at  the  bottom  left 
of  the  screen. 

The  SHIPNAME  drop-down  box  allows  the  user  to 
only  select  customers,  which  have  previously  been  added  to 
the  Customer  table.  If  a  customer  is  not  available, 
minimize  of  close  the  Support  form  and  then  open  the 
Customer  form  and  add  the  new  customer  by  clicking  on  the 
"Add  New  Customer"  button.  Once  the  customer  information 
is  added,  close  the  Customer  table  and  then  maximize  or 
reopen  the  Support  Form  and  select  the  customer  from  the 
drop-down  list. 

As  mentioned  in  the  Tables  section,  the  RTE  is 

required  for  all  entries  in  the  Support  table.  The  RTE  is 
made  up  of  the  INIT,  the  current  year  and  the  sequential 
support  number.  The  INIT  is  the  first  letter  in  the 

commands  location  (S  =  San  Diego,  N  =  Norfolk,  and  Y  = 
Yokosuka)  and  is  set  to  default  to  the  users  value.  The 
current  year  is  set  by  using  the  systems  clock,  so 

depending  on  the  time  settings  that  one  uses  the  clocks 
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could  vary  whether  you  are  using  local  or  GMT  time. 
Finally,  the  Support  Number  is  a  sequential  number  that  is 
set  by  the  system  by  comparing  the  last  value  entered  and 
adding  1.  This  value  will  reset  to  1  upon  the  shift  to  the 
new  year.  These  three  values  make  up  the  RTE,  which  will 
remain  the  same  for  the  remainder  of  the  support  for  this 
track.  Because  these  values  are  automatically  entered  when 
the  new  support  is  added,  these  three  objects  have  been 
removed  from  the  tab  order  and  do  not  normally  receive  the 
focus.  To  change  the  value  of  the  Support  Number,  select 
the  text  box  under  SUPPORTNUM  and  type  in  a  new  value. 
Remember:  The  next  support  value  will  add  1  to  the  modified 
entry  so  you  may  need  to  change  that  value  if  you  are  not 
adding  numbers  sequentially. 

The  classification  of  the  support  is  selected 
from  a  drop-down  menu  and  is  usually  provided  in  the 
MOVREP,  MOVORD  or  OTSR  request  message.  Enter  this  value 
by  typing  the  first  couple  of  letters  to  the  classification 
and  selecting  enter  or  select  the  drop-down  list  and  choose 
the  appropriate  value. 

Both  and  STARTDATE  and  STOPDATE  are  entered  by 
selecting  the  current  status  of  the  support.  If  the 
TR_SUPPORT  changes  from  "PENDING"  to  "OPSNORMAL"  or  "12 
Hourly"  then  the  STARTDATE  will  enter  in  a  DD-MMM-YY 
format,  where  DD  is  day,  MMM  is  month  and  YY  is  the  last 
two  digits  of  the  Year.  Additionally,  the  STOPDATE  is 
entered  when  the  TR_STATUS  changes  from  an  active  type  of 
support  to  "FINAL".  Error  checking  has  been  created  to 
check  if  the  TR_STATUS  has  changed  in  a  manor  which  would 
extend  the  support  of  remove  a  STOPDATE,  such  as  mistakenly 
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selecting  FINAL  before  one  meant  to.  The  tab  order  for 
these  controls  has  also  been  removed  to  avoid  data  entry 
mistakes . 


As  shown  in  Figure  38,  the  values  from  Limits  to 
Customer  Comments  are  associated  with  the  Customer  form. 
To  edit  any  of  these  values,  select  "Open  Full  Customer 
Form",  edit  the  necessary  fields  and  then  click  on  "Save 
and  Close  Form".  The  values  you  have  edited  will  be 
modified  and  the  new  values  will  appear  when  you  return  to 
the  Support  form. 

The  "PRIMARY  METHOD  OF  REQ : "  drop-down  box  is  a 
selection  to  choose  the  method  with  which  this  particular 
support  was  requested.  The  standard  choices  for  this 
object  are  usually.  Movement  Report  (MOVREP) ,  Movement 
Order  (MOVORD) ,  OTSR  request,  e-mail,  or  voice,  however 
additional  choices  can  be  added  by  selecting  the 
"Administration  Form"  and  clicking  on  "Open  Method  of 
Request".  Enter  the  new  value  on  the  next  open  line  and 
close  the  form. 

The  "MOVREP/Pri  Request  DTG"  object  is  the  Date- 
Time_Group  of  the  request  message,  unless  the  request  comes 
from  a  MOVORD  message.  If  the  request  method  does  come 
from  a  MOVORD,  enter  the  value  in  the  "MOVORD  DTG"  box.  In 
the  cases  when  a  customer  provides  both  a  MOVREP  and  MOVORD 
to  request  support,  enter  the  DTG  of  the  messages  in  the 
appropriate  boxes. 

TR_STATUS  is  the  current  operational  status  of 
the  vessel.  The  choices  for  TR_STATUS  are: 

1.  12  Hourly:  This  status  is  used  when  the  vessel 
has  met  or  exceeded  their  current  operational  limits  and  is 
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under  close  watch  from  OTSR  or  under  OTSR  advisory  or 
diverts  (WEAX  every  12  hours)  . 

2.  OPS  NORMAL:  This  status  is  used  when  the  vessel 

is  underway  and  under  their  operational  limits. 

3.  IN  PORT:  This  status  is  used  for  vessels  that  are 

still  under  OTSR  support  and  in  port  for  a  short  duration 
or  OTSR  can  use  this  status  as  a  reminder  that  the  vessel 
is  in  port,  but  not  currently  under  support.  This  would  be 
helpful  for  sending  sortie  messages  and  ensuring  that  all 
vessels  have  been  notified. 

4.  PENDING:  This  status  is  used  for  those  vessels 

that  have  submitted  an  OTSR  request,  but  are  not  currently 
underway . 

5.  FINAL:  Status  used  when  support  for  a  vessel  has 

completed . 

Additional  TR_STATUS  values  can  be  added  by  modifying  the 
"TR_Status  Types"  button  on  the  administration  form.  If  a 
vessel  is  under  12  hourly  status  than  amplifying  remarks 
can  be  added  by  selecting  the  cause  for  the  support  in  the 
"12  Hourly  cause"  drop-down  box.  The  purpose  of  this  box 
is  to  provide  a  reason  for  placing  a  vessel  on  the  current 
support.  This  box  could  be  used  for  all  operational 
status,  however  the  standard  reasons  only  include  those 
that  meet  the  OTSR  advisory  or  divert  criteria. 

The  OTWE_SUPP  box  provides  information  about  what 
support  was  requested  and  will  be  supplied  to  the  vessel. 
The  standard  choices  are: 

1.  AVWEAX:  This  type  is  used  when  the  vessel 
only  requests  aviation  weather  forecast  messages  and 
does  not  require  OTSR  services. 

2.  AVWEAX /OP ARE A :  This  type  is  used  when  the 
vessel  is  located  within  a  local  area  OPAREA,  however 
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due  to  operations  requires  special  information  from 
the  aviation  weather  forecast  message. 

3.  OPAREA:  Type  used  when  vessel  is  operating  in 
local  OPAREA  and  only  requires  a  standard  shipboard 
forecast . 

4.  OTSR:  Type  used  for  vessel  transiting  large 
ocean  basins. 

5.  OTSR/AVWEAX:  Type  used  for  vessels  who  are 
transiting  large  ocean  basins  and  require  an  aviation 
forecast . 

6.  OTSR/WEAX:  Type  used  for  vessels  who  are 
transiting  large  ocean  basins  and  require  a  shipboard 
forecast . 

7.  OTSR/OPAREA:  Type  usually  used  for  vessels 
that  are  conducting  operations  that  may  be  weather 
sensitive  and  require  a  more  watch  eye  from  OTSR 
(e.g.,  towing  operations,  TAGOS  ops,  diving 
operations ) 

8.  WEAX:  Type  used  for  vessels  only  requiring  a 
shipboard  forecast. 

9.  SPECIAL  SUPPORT:  Type  defined  by  local 
center,  may  be  used  for  vessels  not  under  Navy  support 
but  that  may  need  notification  if  a  storm  is  in  the 
general  vicinity  of  the  vessel. 

10.  SOI:  Ship  of  Importance,  could  be  a  carrier 
or  amphibious  vessel  with  an  embarked  meteorology  and 
oceanography  division  (OA  division) .  Messages  are  not 
usually  written  to  a  vessel  of  this  type;  however  OTSR 
coordination  is  required  between  OTSR  and  the  vessels 
OA  division. 

Additional  OTWE  Support  options  can  be  added  by  modifying 
the  OTWE  Support  Types  on  the  Administration  form. 

The  "Special  Support"  text  box  is  a  space  to  add 
any  additional  products  that  a  vessel  may  have  requested. 
If  the  vessel  has  an  embarked  met  on  board,  and  the  met 
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needs  satellite  images  sent  daily  or  if  the  vessel  would 
like  a  graphical  WEAX,  than  this  information  could  be  added 
to  the  form. 

The  "Ships  in  Company"  text  box  is  used  to  list 
additional  vessels  that  will  be  transiting  with  the  lead 
vessel.  This  condition  could  be  permanent  or  temporary 
depending  on  the  operations. 

The  next  section  of  the  Support  form  is  the  most 
important  portion  of  the  entire  form.  This  section  is  the 
departure  and  arrival  information.  If  this  information  is 
not  entered  correctly,  then  vessels  may  be  many  miles  from 
where  the  forecasting  team  expects  the  vessel  to  be.  Both 
the  departure  location  and  the  arrival  location  boxes  are 
simply  a  text  box  used  to  type  in  the  appropriate 
information  received  from  the  MOVREP  or  MOVORD . 
Additionally,  each  location  has  a  departure  or  arrival 
time,  respectively,  that  is  inputted  in  a  DDHHHHMMMYYYY 
format  where  D  is  day,  H  is  hour  and  minutes,  M  is  3  letter 
month  and  Y  is  four  number  year. 

The  next  object  in  our  discussion  is  the  Location 
drop-down  box  which  provide  information  on  where  the  vessel 
is  located  in  relation  to  METOC  products  that  are  being 
produced.  In  order  to  make  the  Electronic  Ship  Folder  a 
one  stop  shop  location  to  review  current  support  and 
valuable  forecasting  tool,  the  system  must  know  where  the 
vessel  is  located.  Once  the  user  select  the  region  of  the 
world  that  the  vessel  is  in,  he  or  she  now  has  access  to 
product  links  that  have  been  established  in  the  Ship 
Location  table  (SHIPLOC) .  As  discussed  in  the  tables 
section  of  this  thesis,  the  linked  products  can  then  be 
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viewed  to  analyze  the  current  situation  or  forecast  the 
upcoming  conditions.  One  can  access  the  links  by  selecting 
the  ship  location,  selecting  the  product  name  and  then 
clicking  on  the  View  Product  command  button. 

The  final  user  input  to  this  form  is  the 
OT_Comments  block  which  is  used  for  the  on  watch  router  to 
provide  comments  to  the  next  on  coming  watches.  This  block 
usually  contains  information  about  conversations  that 
occurred  during  the  watch,  or  possible  routing  scenarios. 
This  information  should  be  kept  as  current  and  in-depth  as 
possible . 

Except  for  the  command  buttons  that  are  labeled 
according  to  their  task,  the  only  other  feature  of  the 
Support  Form  is  the  Quick  Search  section  in  the  lower  right 
hand  portion  of  the  form.  In  this  portion  of  the  form,  the 
user  can  quickly  access  the  needed  RTE,  Ship  Name  or  view 
the  current  support  by  track  status.  Additionally,  message 
traffic  pertaining  to  the  current  RTE  is  available  by  using 
the  Message  buttons  at  the  bottom  of  the  page. 
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Figure  41:  Support  Entry  Form 


The  last  major  form  that  is  used  in  the  program 
is  the  MESSForm  (Fig.  42) .  This  form  is  used  to  access  the 
many  messages  that  are  being  added  to  the  system  daily  as 
message  traffic  enters  the  command.  The  MESSForm  is  used 
to  view  the  data  which  has  been  added  to  the  Message  table 
and  formatted  for  easier  reading  than  reading  from  the 
tables.  One  feature  that  is  available  from  the  MESSForm  is 
the  ability  to  enter  new  support  while  having  the  message 
displayed  on  the  active  screen.  This  helps  to  avoid  some 
human  error  when  translating  the  information  from  one 
screen  to  another  or  from  paper  to  screen.  To  add  new 
support  from  the  MESSForm,  find  the  message  that  you  wish 
to  enter  into  the  database  and  select  the  button  that 
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reads,  "Add  New  Support  Using  this  Message".  This  action 
will  open  Figure  43  and  allow  the  user  to  have  easy  access 
to  the  required  messages  while  entering  the  data. 
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Figure  42:  Message  Form  used  to  Review  Message  Traffic 

and  Provide  an  Easy  Method  to  Add  New  Support 
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Figure  43:  New  Support  QuickForm  used  to  View  Message 

Traffic  While  Entering  Support  Data 


c.  Reports 

The  standard  program  comes  with  two  primary 
reports,  the  OTSR  Turnover  Report  and  the  Current  Status 
Report.  The  OTSR  Turnover  Report  is  produced  from  several 
queries  that  organize  the  12  Hourly,  OPS  Normal,  INPORT  and 
Pending  vessels.  This  report  contains  the  information 
needed  to  provide  a  proper  turnover  to  the  next  watch  (e.g, 
status  of  the  vessel,  departure  and  arrival  locations  and 
times,  message  DTG's,  and  turnover  comments.  The  Current 
Status  form  is  a  much  more  abbreviated  report  that  would  be 
provided  to  the  chain  of  command  for  general  awareness  of 
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the  OTSR  support.  Using  Access's  report  generation  tool 
additional  reports  can  be  generated. 

d.  HTML  Display 

The  HTML  web  pages  are  created  based  on  the  12- 
hourly  and  ops  normal  customers.  The  pages  are  only 
generated  if  the  particular  messages  or  supporting  html 
page  is  available.  If  for  instance,  a  support  vessel  does 
not  have  WEAX  or  operational  messages  the  WEAX  and  OPS 
links  will  not  be  available.  If  the  vessel  does  not  have 
any  messages  associated  with  its  route  number,  than  that 
ship  will  not  be  available  on  the  support  page.  Figures  44 
through  46  show  representative  html  documents. 
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OTSR  Index.html  File 


71 


Figure  45:  Individual  Ship  Support  Page 
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Message  Type  Support  Page 
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6. 


Program  Operation 


Operation  of  the  ESF  database  is  very  easy  with  a 
little  understanding  of  the  basic  operation  of  the  program 
itself  and  Access  2000.  The  instructions  in  this  chapter 
provide  a  very  good  overview  on  how  the  program  should  be 
used  and  how  information  should  be  entered  into  the 
program.  As  mentioned  before,  the  ESF  program  can  be 
operated  from  a  network  or  stand  alone  PC.  If  the  program 
is  placed  on  a  network  drive,  responsibilities  for 
maintaining  the  data  can  be  dispersed  to  several 
individuals,  however  one  administrator  can  easily  operate 
this  program.  These  basic  procedures  should  be  followed  in 
maintain  the  ESF  database. 

1.  Ensure  that  all  current  and  near  future  customer 
have  been  added  to  the  Customer  Form. 

2.  Ingest  messages  from  the  Message  Parsing  Program 
as  often  as  the  files  are  available.  This  keeps  the  number 
of  ingest  files  to  a  smaller  and  more  manageable  number. 

3.  Review  messages  frequently  and  utilize  the  New 
Support  QuickForm  to  enter  the  available  information  from 
the  message. 

4.  For  easier  tracking  of  messages,  be  sure  to  change 
the  message  type  from  general  to  the  appropriate  value  if 
the  messages  where  not  properly  parsed. 

5.  Update  the  support  information  by  using  the 
Support  Form  on  the  main  startup  form.  Be  as  detailed  as 
possible  when  updating  the  OTSR  comments. 

6.  Output  html  documents  once  all  support  data  is 
updated  by  clicking  in  the  "Create  HTML  Page"  button  from 
the  startup  form. 
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IV.  TESTING  AND  EVALUATION 


In  this  chapter,  the  operational  concept  (OPCON) ,  data 
flow  and  the  test  results  will  be  discussed.  The  JMV  and 
METCAST  software  modifications  and  concept  of  operations, 
along  with  the  initial  version  of  the  Message  Parsing 
Program  were  tested  during  Fleet  Battle  Experiment  Juliet 
(FBE-J)  in  San  Diego.  A  second  test  to  evaluate  the  final 
version  of  the  Message  Parsing  Program  and  the  Electronic 
Ship  Folders  concepts  was  conducted  in  the  classified  lab 
at  the  Naval  Post  Graduate  School  (NPS) .  An  Operational 
Concept  (OPCON)  was  developed  to  describe  how  the  various 
programs  work  in  an  operational  environment. 

A.  FBE-J  TEST 

Tests  were  conducted  during  FBE-J  between  July  and 
August  2002  to  demonstrate  ship  track  and  HWD  production 
and  distribution.  The  distribution  of  XML  data  was  tested 
between  several  JMV  users  as  well  as  to  the  Polexis  Web  COP 
called  Viewpoint.  Additionally,  the  production  and 
distribution  of  shape  files  was  tested  to  ensure  that  these 
files  could  be  used  by  ESRI  viewers.  Additional  goals  and 
requirements  were  established  during  FBE-J  for  the  Polexis 
software;  however,  for  this  thesis  only  the  product  ingest 
and  display  of  JMV  products  were  tested. 

1 .  Operational  Concept 

The  OPCON  for  this  test  was  to  create  HWD's  and  ship 
tracks  using  the  MPP  and  JMV,  publish  these  products  and 
make  them  available  for  customer  download.  For  this  test 
the  METCAST  and  Polexis  software  were  used  to  download  the 
finished  products,  however  any  web  enabled  application  that 
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understands  XML  formatted  messages  can  be  used.  .  This 
test  simulated  the  production  of  products  from  a  typical 
METOC  center  and  demonstrated  how  centers  can  collaborate 
to  combine  products  and  thus  create  a  larger  support  area 
of  collaborated  products.  This  type  of  product  production 
would  be  used  to  create  a  regional  or  global  HWD  where 
centers,  facilities  or  detachments  could  provide  inputs  to 
a  central  coordinator  who  fuses  the  products  into  one. 
Depending  on  the  claimancy  CONOPS,  this  coordinator  could 
be  single  "Super  Center"  that  is  responsible  for  half  the 
world  or  a  coordinated  effort  between  commands  on  the  same 
echelon  level.  In  our  current  center  architecture  where 
each  center  is  run  by  an  METOC  Captain  and  command 
boundaries  are  closely  aligned  with  Fleet  responsibilities, 
coordination  is  required  to  prepare  products  that  overlay 
properly  at  boundaries.  Today,  coordination  is  conducted 
over  the  phone  or  over  Internet  Relay  Chat  (IRC)  .  By 
coordinating  the  boundaries  prior  to  creating  the  product, 
producers  can  quickly  negotiate  and  correct  and  differences 
at  the  boundaries.  Once  producers  agree  on  the  collaborated 
product  the  operational  attribute  is  turned  on  and  the 
product  is  now  available  to  operational  customers. 

2 .  Data  Flow 

Figure  47  describes  the  data  flow  from  product 

generation  to  dissemination  and  then  to  product 

availability.  Products  are  produced  by  a  METOC  center 
using  JMV  and  published  using  METCAST  (File | Publish  Drawing 
for  HWD's,  the  Publish  button  on  the  ship  route  editor  for 
ship  tracks) .  The  publishing  agent  is  called  w-shove  and 
is  used  to  push  the  product  with  associated  attributes  to 

the  METCAST  server  where  the  product  is  placed  in  a 
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channel.  Once  the  product  is  in  the  channel,  it  is 
available  for  download  by  other  METCAST  clients  and 
applications  that  used  the  METCAST  discovery  and 
subscription  services. 

Data  Flow  for  FBE-J  lest 


Product*  Kfnmfti  la 

JJKldMl  Li'JtL'lrftU  vui 

METCWST  Tielll 


Figure  47:  Data  Flow  for  FBE-J  Test 

3.  Results 

Initially  MPP  generated  ship  tracks  were  placed 

directly  into  the  JMV  tracks  directory.  The  initial 

version  of  the  MPP  correctly  parsed  about  50%  of  the 

MOVREPs  that  it  was  fed.  For  those  files  that  were  not 

parsed  correctly,  manual  modifications  to  the  files  had  to 
be  made.  In  most  cases,  the  modified  files  corrected  most 
file  errors.  For  those  errors  that  even  manual  corrections 
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could  not  fix,  the  tracks  were  manually  entered  into  JMV' s 
ship  route  editor.  In  general,  errors  with  the  MPP  were 
due  to  improper  formatting  and  additional  spaces  in  the 
messages.  Once  the  tracks  were  displayable  in  JMV,  the 
messages  were  converted  to  XML  and  successfully  published 
to  the  METCAST  server  100%  of  the  time.  All  published 
products  that  were  successfully  displayed  on  both  JMV  and 
Polexis  displays.  The  ease  of  publishing,  retrieving  and 
updating  was  tested  by  creating  separate  Eastern  and 
Western  Pacific  HWD's,  publishing  the  products,  and 
downloading  them  to  a  local  system.  Once  the  files  were 
downloaded,  both  files  were  imported  to  the  JMV  display. 
In  some  cases,  differences  were  created  at  the  boundaries 
to  verify  that  corrections  could  be  made  to  the  existing 
files  and  could  be  updated.  In  every  case,  the  new  product 
either  wrote  over  the  existing  product  or  a  new  product  was 
generated  as  desired.  Figures  48  through  63  graphically 
depict  the  process  of  producing  two  separate  forecasts  and 
merging  them  into  one. 
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Figure  48:  Creation  of  West  Pacific  HWD 


The  first  step  in  creating  any  combined  forecast  is  to 
create  the  individual  forecast  pieces.  During  the  exercise 
users  produced  a  Western  Pacific  HWD  that  included 
parameters  such  as  locations  of  highs,  lows,  fronts,  wind 
barbs  and  other  weather  phenomena  associated  with  the  area 
of  concern.  Boundaries  at  the  180°  or  any  other  METOC 
center  boundary  were  coordinated  over  the  phone  or  using 
IRC  chat.  Once  the  points  are  determined  the  individual 
centers  create  the  final  product. 
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Figure  49:  Publishing  West  Pacific  HWD  (Form  1) 

Figures  49  and  50  represent  the  process  to  upload  the 
files  to  the  METCAST  server.  For  this  test,  the  METCAST 
server  was  located  at  FNMOC;  however,  when  the  TEDS 
installs  are  completed  at  all  the  local  METOC  centers  local 
server  could  be  used.  Figures  51  through  53  show  the 
process  to  publish  the  Eastern  Pacific  HWD.  The  process  is 
the  same  as  that  performed  for  the  Western  Pacific  area, 
except  that  the  parameters  in  the  two  publishing  forms 
contain  slightly  different  attribute  data.  Once  the  HWD 
XML  files  are  pushed  to  the  server,  the  files  are 
accessible  from  the  METCAST  channels  dialogs  (Fig.  54)  . 
First,  open  the  METCAST  client  and  select  the  Options  then 
Channels  menu  item.  Download  the  product  by  clicking  on  the 
down  arrow  in  Figure  54  and  selecting  the  whole  channel  or 
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a  portion  of  the  channel  filtered  by  attribute  (Fig.  55)  . 
Once  the  file  has  been  downloaded,  select  the  map  of 
interest  and  click  on  File | Import  Drawing  (Fig.  56  and  57) 
to  add  the  first  HWD  file.  To  add  the  second  drawing, 
click  on  File  |  Append  Imported  Drawing  (Fig.  58  and  59)  to 
add  any  number  of  other  overlays  to  the  existing  graphic. 
By  importing  the  file  rather  than  adding  it  through  the 
standard  product  selector,  a  user  is  able  to  modify  the 
files  (Fig.  60  through  62)  and  publish  the  changes  (Fig. 
63)  . 


Figure  50:  Publishing  West  Pacific  HWD  (Form  2) 
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Figure  51:  Creation  of  East  Pacific  HWD 
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Publishing  East  Pacific  HWD  (Form  1) 
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Figure  53:  Publishing  East  Pacific  HWD  (Form  2) 
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Figure  54:  Accessing  HWD  channel 
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Figure  55:  Retrieving  HWD  Products 
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Figure  57 :  Importing  East  Pac  HWD 


Figure  58:  Appending  WPAC  HWD 


85 


Figure  59:  Complete  Pacific  HWD  with  Mismatched 

Crossing  Point 


Figure  60:  Mismatched  Crossing  Point  (Blow-up) 
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Figure  61:  Adjusting  WPAC  Product 
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Figure  62:  Adjusting  EPAC  Product 
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Finally  we  tested  production,  publication  and 
subscription  of  ESRI  shape  files.  Since  ESRI's  shape  format 
arbitrarily  assigns  colors,  an  additional  file  is  required 
to  associate  color  with  the  published  shape  file.  Depending 
on  the  version  you  are  using,  the  format  and  file  extension 
of  this  file  differs.  In  ARCINFO  version  3.2  this  file  is 
a  . avl  file  and  is  generated  by  ESRI  software.  To  make  the 
shape  file  more  useful,  a  .avl  equivalent  file  needs  be 
created  by  JMV  to  allow  normal  METOC  symbology  to  be 
displayed  properly. 

The  shape  files  are  created  from  the  downloaded  XML 
files.  As  described  in  Chapter  III,  the  XML  files  are 
converted  to  shape  by  using  an  executable  program,  which  is 
currently  separate  from  JMV.  These  files  were  successfully 
created  and  then  opened  in  ARCVIEW  3.2  for  display.  To 
solve  the  color  problems,  all  HWD's  are  named  the  same  and 
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the  .  avl  files  were  created  and  associated  with  each  HWD 
f  ile . 

B.  NPS  TEST 

This  test  was  conducted  from  the  2nd  to  the  6th  of 
September  with  the  purpose  of  testing  the  operation  of  the 
Message  Parsing  Program,  the  Electronic  Ship  Folder  and  how 
the  outputs  from  the  MPP  (ship  tracks  and  observations) 
were  ingested  and  displayed  in  the  current  JMV 
architecture . 

1 .  Operational  Concept 


The 

OPCON  for  this 

test  was 

to  provide  a  set 

of 

programs , 

which  ingested 

operational 

message 

traffic 

and 

provided 

the  output  to 

a  support 

tracking 

system. 

the 

Electronic  Ship  Folder,  and  graphical 

display 

program. 

JMV. 

Additionally,  output  from  the  database  must  be  provided  to 
area  Fleet  Commanders  through  an  easy  to  use  web  page. 
This  web  page  should  contain,  at  a  minimum,  the  currently 
supported  vessels,  a  graphic  of  the  track  and  links  to  the 
available  message  traffic.  The  last  requirement  was  that 
the  data  be  available  in  a  format  which  could  be  combined 
with  other  OTSR  center  data  to  create  a  system  that  was  not 
only  interoperable,  but  could  be  used  by  a  center  as  a 
backup  tool,  in  the  event,  that  another  center  needed  them 
to  provide  backup  services  for  an  extended  duration  of 
time.  By  having  a  system  of  programs  that  can  parse, 
track,  disseminate  and  backup  the  currently  used  bits  of 
OTSR  information,  the  OTSR  program  would  have  a  more 
operationally  useful  tool  to  conduct  the  business  of 
supporting  ships.  This  system  would  reduce  the  amount  of 
time  it  took  to  review  and  enter  various  types  of  message 
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data  and  would  reduce  the  manpower  required  to  maintain 
current  OTSR  web  pages. 

Manual  data  entry  at  each  center  should  be  limited  to 
only  those  vessels  that  are  currently  being  supported  by 
that  individual  center.  Messages  being  parsed  and  placed 
into  the  database  as  specific  message  types  (i.e.,  WEAX, 
MOVREP,  OBSERVATION,  ETC.)  should  be  reserved  for  messages 
that  affect  center  supported  vessels  or  those  messages  that 
are  being  sent  by  customers  (i.e.,  observations  or  MOVREPs) 
that  would  be  more  difficult  to  separate.  Since  the 
parsing  program  can  separate  between  active  vessels  (those 
being  supported  by  the  center  using  the  database)  and  non¬ 
active  vessels  (those  not  being  supported  by  the  center 
using  the  database) ,  these  two  groups  of  messages  should  be 
separated  by  directory  and  through  database  queries  to 
reduce  overlap  between  supporting  and  non-supporting 
centers . 

2 .  Data  Flow 

Figure  64  provides  a  graphic  of  the  data  flow  from 
NPMOC  through  the  processing  path.  The  data  flow  required 
messages  that  were  provided  by  the  watch  from  NPMOC  San 
Diego,  and  were  transmitted  to  NPS  via  an  ftp  transfer. 
Messages  are  in  an  ASCII  text  format  and  where  ingested 
into  the  MPP  to  determine  the  message  type.  Once  the 
message  type  was  determined,  parsing  criteria  determined 
whether  the  particular  message  was  to  be  parsed  to  the 
database,  to  JMV  or  moved  to  a  new  location.  If  a  message 
type  was  not  determined,  then  the  message  was  parsed  to  the 
database  and  the  file  was  moved  to  a  general  directory, 
located  on  the  hard  drive.  As  shown  in  Figure  42,  the 
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database  output  from  the  MPP  provides  the  RTE  (if 
available) ,  SHIPNAME,  DTG,  Subject,  message  type,  a  link  to 
the  message  file,  and  the  parsed  text  of  the  message.  This 
text  could  vary  depending  on  the  message  type  and  the 
processing  by  the  MPP. 

Once  the  messages  were  processed,  the  database  import 
file  (mess.txt)  is  imported  by  the  ESF  database  to  feed  the 
Messages  table.  Database  users  then  review  the  message 
traffic  from  the  Messages  Form.  While  using  the  Message 
Form,  support  can  be  added  or  updated  by  manually  editing 
the  support  data  using  the  information  contained  in  the 
messages.  While  the  user  is  reviewing  the  traffic,  the 
message  type  and  route  number  are  reviewed  for  accuracy. 
This  information  is  later  used  for  the  html  web  page 
creation.  While  the  messages  are  being  reviewed,  the 
user' s  login  is  added  to  the  userid  field  to  allow  the  user 
to  know  when  all  the  messages  have  been  review. 

In  addition  to  the  files  provided  to  the  ESF  database, 
files  are  also  provided  to  JMV.  The  individually  decoded 
MOVREP  and  decoded  observation  file  are  created  and  made 
available  to  the  user  to  provide  to  JMV.  The  MOVREP  files 
can  be  automatically  added  to  the  JMVWIN\NODDSFLS\ TRACK 
directory  if  the  user  selects  this  directory  within  the 
MPP.  However,  the  decoded  observations  are  added  to  the 
file  jmvobs.dat  and  must  be  pasted  into  the  appropriate  SEA 
SYNOPTIC  REPORTAOSA'A''A''A''A'0/'N/NS/N  .  JMV  file  within  the  users  JMV 
area  directory.  Because  JMV  or  METCAST  have  the  potential 
to  make  many  area  boxes,  the  individual  user  will  need  to 
select  the  area  they  wish  to  add  the  files  too. 
Additionally,  only  the  most  recent  observations  will  be 
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kept  in  the  JMV  file  since  JMV  is  an  operational  system  and 
is  not  routinely  used  for  data  archiving  or  reviewing 
historical  events.  Once  the  MOVREP  is  parsed  and  placed 
into  JMV,  the  track  is  exported  as  a  graphic  and  saved  to 
the  designated  directory.  For  this  test  an  images  directory 
was  added  to  the  \ JMVWIN\NODDSFLS\TRACKS  directory.  Once 
the  file  is  created,  the  image  is  added  to  the  tracks  tab 
(Fig.  65)  in  the  ESF  database.  These  tracks  are  later  used 
in  the  web  page  generation. 
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NPS  Test  Data  Flow 
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Figure  65:  Ship  Track  display  on  Ship  Track  Tab  of  ESF 

database 


Now  that  the  messages  have  been  parsed,  support 
database  is  updated,  JMV  files  have  been  created  and 
imported  to  the  database,  the  web  page  generator  is  ready 
to  be  utilized.  The  web  page  is  created  by  clicking  on  the 
"Create  HTML  Page"  on  the  Startup  form.  This  generates  an 
index.htm  file  that  provides  a  listing  of  all  12  hourly  and 
OPS  NORMAL  ships  under  support,  a  SHIPNAME.htm  file  that 
contains  links  to  the  available  messages  for  that  ship  and 
available  track  image,  and  finally  a  SHIPNAME_MESS.htm  file 
that  contains  the  links  to  the  individual  message  files. 
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3. 


RESULTS 


The  overall  operation  of  the  existing  system  was 
satisfactory;  however,  as  the  test  progressed  several 
deficiencies  in  the  program  operation  and  design  where 
apparent.  The  results  of  the  individual  programs  will  be 
discussed  in  this  section  with  additional  requirements  to 
address  deficiencies  being  added  and  discussed  in  Chapter 
V. 

a .  Message  Parsing  Program 

Overall,  the  program  parses  messages  correctly 
with  both  MOVREPs  and  Observations  being  decoded  and  JMV 
files  generated.  In  general,  MOVREPs  were  correctly 
processed  about  70%  of  the  time  with  observations  that 
contained  the  BBXX  identifier  being  parsed  approximately 
90%  of  the  time.  For  MOVREP  files,  errors  were  generated 
when  incorrect  latitude  and  longitude  points  were  found  for 
the  ETA  and  ETD  lines  that  only  contained  a  port  name  and 
not  a  lat/long  position  or  when  other  data  was  missing  from 
the  messages  like  ship's  speed.  As  an  example,  a  MOVREP 
was  submitted  with  the  track  going  from  Okinawa  to  Sasebo, 
Japan.  When  the  parser  searched  the  port  list  file  for  the 
word  Sasebo,  it  matched  to  the  word  Aseb.  The  program  does 
compare  latitude  and  longitude  hemispheres;  however,  since 
Sasebo  and  Aseb  are  in  the  same  hemispheres  the  file 
processed  normally.  Through  this  test,  it  is  easy  to  see 
that  much  more  detailed  programming  is  required  to  parse 
the  messages  to  a  higher  degree  of  completeness.  All  files 
that  were  run  through  the  program  were  parsed  into  the 
database,  except  for  when  fatal  errors  occurred  with  the 
program.  These  errors  usually  occurred  when  twenty  or  more 


94 


messages  where  parsed  at  one  time  and  incorrect  data  values 
or  missing  data  were  processed.  Additional  errors  occurred 
when  the  program  did  not  seem  to  initialize  or  reinitialize 
correctly  with  the  right  variables.  These  errors  could 
easily  be  eliminated  with  a  more  complete  understanding  of 
Windows  based  programming  in  Visual  Basic  (program 
operations,  file  operations,  etc.). 

jb.  Electronic  Ship  Folder  Database 

The  operation  of  the  database  was  very  reliable. 
Messages  were  entered  into  the  database  very  quickly  and 
the  OTSR  support  data  could  be  updated  very  rapidly.  Once 
all  data  was  updated,  the  web  pages  were  generated  without 
any  missing  data  and  products  were  available.  One  problem 
was  found  with  the  ability  to  import  some  long  messages 
into  the  message  field  of  the  Message  table. 

In  some  cases,  messages  were  truncated  due  to 
their  length  and  only  some  portion  of  the  message  was 
available  for  review.  Clicking  on  the  link  to  the  file  and 
reviewing  the  text  message  could  overcome  this  problem. 
One  reason  for  this  error  was  that  Access  table  fields  do 
not  seem  to  except  general  ASCII  string  formatting  and  line 
feeds  were  not  accepted  to  format  the  message  properly.  In 
order  to  fix  this  problem,  extra  spaces  were  added  to  fill 
all  lines  to  69  spaces  and  then  the  forms  were  adjusted  to 
fit  the  font;  Courier  New,  10.  This  added  unnecessary  file 
size  and  exceeded  the  65,536  character  limit  of  a  memo 
field.  In  most  cases,  METOC  Messages  were  not  affected  by 
this  error. 
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V. 


SUMMARY  AND  RECOMMENDATIONS 


A.  THESIS  SUMMARY 

Today' s  military  decision  makers  have  the  challenge  of 
receiving  and  processing  more  data  than  has  ever  been 
available  before.  In  addition,  decision  makers  must  also 
make  decisions  faster  than  in  the  past  since  our 
communications,  as  well  as  our  enemies  systems  and  reaction 
times  have  been  greatly  improved.  In  order  for  METOC 

products  and  services  to  be  viable  to  the  decision  makers, 
products  must  be  fully  integrated  into  the  decision  makers 
system.  This  thesis  has  investigated  several  means  to 
improve  the  interoperability  of  METOC  products  and  services 
by  improving  the  tactical  significance  of  our  products, 
accessibility  to  our  data,  and  interoperability  between  our 
internal  command  systems . 

In  order  to  improve  the  interoperability  of  JMV  and 
METCAST  the  following  capabilities  were  added: 

1.  Re-engineered  the  METCAST  Server  to  allow  multiple 
product  types,  as  well  as  multiple  product  variations. 

2.  Created  communicat ion  path  between  JMV  and  METCAST  to 
allow  JMV  overlays  to  be  pushed  to  the  METCAST  server. 

3.  Developed  user  interface  to  publish  products  from  JMV 
and  retrieve  products  from  the  METCAST  server. 

4.  Designed  ESRI  shape  file  export  capability. 

In  order  to  improve  the  interoperability  of  the  Navy 
METOC  OTSR  program  the  following  capabilities  were 
demonstrated : 
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1.  Created  a  message  parser  that  scanned  operational 
message  traffic  and  provided  output  to  the  database  and 
JMV . 

2.  Upgraded  existing  database  design  to  include  all  OTSR 
data,  which  is  currently  maintained  in  paper  folders. 

3.  Designed  database  format  to  be  easily  transferable 
between  systems  to  provide  backup  capabilities  between 
centers . 

4 .  Provided  web  output  from  database  to  provide  quick 
access  to  all  available  OTSR  data. 

B.  RECOMMENDATIONS  FOR  FURTHER  IMPROVEMENTS 

1 .  Improved  Integration  of  Shape  File  Exporter 

The  Current  method  of  converting  XML  HWD's  or  Ship 
Tracks  requires  users  to  utilize  a  separate  executable 
program  requiring  them  to  leave  the  JMV  environment.  Since 
this  method  is  outside  the  normal  operations  of  the  program 
the  procedures  are  much  more  confusing  and  increases  the 
training  requirements  for  the  program.  This  programs  needs 
to  be  incorporated  into  the  current  JMV  architecture  with 
standard  Windows  based  programming  structure  to  determine 
where  the  XML  file  is  located  and  where  the  program  should 
place  the  converted  file. 

2 .  Better  Integration  of  Message  Parsing  Program  and 
Electronic  Ship  Folder  Database 

In  order  to  make  the  programs  more  efficient  and  more 
user-friendly,  the  Message  Parsing  Program  and  Electronic 
Ship  Folder  Database  should  be  combined  into  a  single 
program  that  handles  the  message  parsing  and  data  tracking 
duties  of  the  OTSR  Program.  Improved  error  and  data 
quality  checking  must  to  be  utilized  to  ensure  that  the 
support  data  is  entered  into  the  database  correctly. 
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Additionally,  wherever  possible,  parsed  messages  should 
provide  inputs  to  the  support  database  automatically  to 
reduce  the  time  that  users  must  manually  enter  data.  As  an 
example,  MOVREP  received  by  ships  in  centers  AOR  should  be 
automatically  entered  with  a  notification  screen  telling 
the  router  that  a  new  request  has  arrived. 

3 .  Improved  Graphical  Display  Capabilities 

Since  the  current  graphical  interface  utilizes  the  JMV 
display  tools  and  does  not  have  its  own  inherent  system, 
the  currently  program  is  limited  to  displaying  only  those 
products  that  JMV  displays.  Since  JMV  is  an  operational 
system,  it  does  not  allow  historical  observations  or  tracks 
to  be  displayed  simultaneously.  One  graphic  that  should  be 
available  is  a  display  that  contains  all  the  observations 
that  were  received  by  a  certain  vessel  for  each  route 
number.  This  not  only  provides  verification  of  position, 
but  provides  and  quick  mechanism  to  verify  forecasts. 
Additionally,  other  graphical  products  such  as  a  ship  track 
with  current  satellite  data,  or  a  meteogram  using  the  ships 
observational  data  would  be  very  valuable  to  OTSR  routers. 
Appendix  A  displays  several  other  products  which  this 
author  believes  should  be  incorporated  into  the  graphical 
display  from  this  program. 

4 .  Improved  Statistical  Analysis 

The  current  ESF  database  only  provides  access  to  the 
text  messages  and  requires  the  user  to  manually  parse  a 
majority  of  the  needed  information  within  the  message. 
Improved  data  parsing  is  required  to  allow  the  system  to 
have  access  to  specific  data  types  that  would  be  useful  to 
the  user  of  the  system.  As  an  example,  observations  need 
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to  be  parsed  in  finer  detail,  in  order  to  track  the 
individual  parameters  of  the  observation  for  trend  analysis 
or  graphical  displays  (e.g.,  graphic  of  changing  wind  speed 
and  direction  with  time  or  sea  and  swell  wave  height  data) . 

C .  OPERATIONAL  IMPLEMENTATION 

All  JMV  and  METCAST  upgrades  are  under  review  to  be 
implemented  as  operational  products  in  the  next  SPAWAR' s 
release.  The  ability  to  transfer  HWD's  and  ship  tracks 
between  METCAST  users  is  needed  by  all  METOC  Regional 
centers,  not  only  to  support  internal  requirements,  but 
also  to  supply  JMV  created  products  to  their  local  customer 
base.  Dialogs  have  been  initiated  between  the  centers  to 
provide  necessary  training  and  guidance  to  implement  the 
system  in  the  near  future. 
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APPENDIX  A:  OTSR  GRAPHICAL  DISPLAYS 


This  appendix  shows  several  examples  of  products  that 
should  be  available  from  an  graphical  display  system  that 
is  incorporated  in  an  OTSR  routing  support  tool. 


Figure  66:  Modified  Meteogram  using  Ship  Observations 

and  Model  Forecasts 


101 


Figure  67:  Ship  Position  with  Model  Pressures, 

Scatterometry  Winds,  Buoy  Observations  and  Visual  Satellite 

Images 


Figure  68:  Satellite 

Heights,  Mean  Sea  Level 


Overlaid  with  Model  Surface 
Pressure  and  Surface  Winds 
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Figure  69:  Satellite  with  Significant  Wave  Period 


Figure  70:  Satellite  with  Sea  Surface  Temperatures 
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